[Datetime-SIG] Timeline arithmetic?
carl at oddbird.net
Mon Sep 7 22:50:42 CEST 2015
> On Sep 7, 2015, at 2:04 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> 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."
More information about the Datetime-SIG