[Datetime-SIG] Timeline arithmetic?

[Guido van Rossum]

On Mon, Sep 7, 2015 at 1:04 PM, Tim Peters <tim.peters at gmail.com> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150907/9a723bb7/attachment.html>