> On Sep 7, 2015, at 2:04 PM, Tim Peters <[email protected]> wrote: > > [Guido] >> But here's a fundamental difference between a timezone-aware datetime and a >> POSIX stamp (apart from epoch, range and precision). The difference applies >> only to "political" timezones, which may change offsets or DST rules. The >> difference is that an aware datetime says "in timezone Z, when the local >> clock says T". If T is in the future, politicians may change the mapping of >> T to UTC in Z. However, politics can't change the meaning of a POSIX >> timestamp. Even for T in the (distant) past the mapping may still change, >> when research finds that the rules for Z were different at some year in the >> past than they were presumed. So, to me, an aware datetime *fundamentally* >> differs from a POSIX timestamp, and even from a pair composed of a POSIX >> timestamp plus a tzinfo object. > > The last is unclear to me, unless it's a conceptual distinction with > no visible consequences.
A <posix time stamp, tz> pair is what I've been calling a "model A aware datetime." A <naive time, tz> pair is what I've been calling a "model B aware datetime." There are many visible differences if you assume that in both cases you do simple integer arithmetic and comparisons on the time stamp component. > An aware datetime _is_ a <naive datetime, > tzinfo> pair, and there's a natural bijection between naive datetimes > and POSIX timestamps (across all instants both can represent). I don't understand this, and I suspect it's at the heart of our misunderstanding. I would say there are many possible bijections between naive datetimes and posix time stamps, one corresponding to every possible UTC offset. (Or if you allow that a naive datetime may represent a time in a zone with a non fixed offset, there may not be a bijection to posix time stamps at all). How do you decide which one is "natural"? Without the offset, you don't know how to compare a naive datetime to an instant expressed as a posix time stamp, meaning you don't actually know what instant it represents. > That a > time_t is "in UTC" is as inconsequential for this purpose as that to > compute 3+1 I happen to have 3 turtles in mind rather than the > distance in meters to my refrigerator ;-) I do see that it's useless > conceptual baggage (even potentially misleading) to drag UTC into it > at all. > > >> (POSIX timestamps are however embeddable in datetimes by using a >> fixed-offset tzinfo.) > > Or use a naive datetime, for all practical purposes. > Conceptually, sure, if you're willing to assume an implied fixed offset timezone. "For all practical purposes," no, because the _practical_ purpose of a model A tz-aware datetime is to always be able to easily and unambiguously ask it "how do you spell yourself in timezone X." Carl _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
