On Mon, Sep 7, 2015 at 1:04 PM, Tim Peters <[email protected]> wrote:
> [Guido] > > Again, I can't follow this because I don't recall the definition of > model A. > > Pretty much that an aware datetime is exactly and only a spelling of a > POSIX timestamp. Various things follow from that, such that timeline > arithmetic is overwhelmingly most natural in that model. > OK. I'll just remember "model A bad, model B good." :-) Or, perhaps more fairly, "model A is how pytz thinks, model B is how the stdlib thinks." > > 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. 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). 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. > OK, you nerd-sniped me. :-) In my view it *is* important that a time_t references UTC. Using a time_t to store a non-UTC timestamp feels as wrong to me as using it to store a number of turtles (even though I know there is code that does this). OTOH a naive timestamp does not have this prejudice towards UTC -- it *could* refer to UTC (e.g. when it's returned from utcnow()) or to local time (e.g. from now()) or to some other timezone that is only inferred from the context. (A struct tm also doesn't have this prejudice to me.) Anyways, when I say "a (POSIX timestamp, tzinfo) tuple", the way I think of it is that when I ask "what does the local clock say" this uses a mapping from POSIX timestamp to that tzinfo. But when I say "a (naive datetime, tzinfo) tuple", I assume the naive datetime to be what the local clock says, so the tzinfo is only needed when I ask "what time is it in another timezone". Next, whatever the future of UTC relative to TAI or other time standards, I expect that UTC will continue to approximate mean solar time somewhere in Greenwich(*), and I expect that the vast majority of other timezones will continue to be defined in terms of offsets from UTC (and typically in whole hours). But I expect that the exact definition of many local timezones will continue to be modified by local politicians, and as a consequence I cannot be *sure* what UTC will be at noon on June 3rd 2020 in the US/Eastern timezone. But I *can* be (tautologically) sure what the local clock will say: 12:00:00. And what I intend by all this is that when I pickle or otherwise persist that particular datetime, I want to be sure that it records the naive local time and the timezone, not the UTC time and the timezone. (Also, I want it to record the timezone in a way that if I unpickle it years from now, it will reference the US/Eastern timezone as it is defined at that time -- I don't want it to reference a copy of the timezone rules at the time I pickled it. This is similar to how globals such as classes and functions are pickled by reference.) I should also mention that this only matters when you persist an aware datetime and restore it later. I don't think we should worry about timezone definitions to be mutable within a process (though if processes were to have expected lifetimes measured in years you might have to worry about this -- but that worry is derived from more general worries about software upgrades over such timescales). > > (POSIX timestamps are however embeddable in datetimes by using a > fixed-offset tzinfo.) > > Or use a naive datetime, for all practical purposes. > As long as the naive datetime is specified in UTC. :-) (*) I visited the Royal Observatory this summer, and learned that there are a number of different competing meridians. It's fascinating to realize that as early as the 19th century astronomers cared about the location of their telescopes to within meters: https://en.wikipedia.org/wiki/United_Kingdom_Ordnance_Survey_Zero_Meridian . -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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/
