[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Carl Meyer]

On 09/14/2015 03:23 PM, Random832 wrote:
> Well, you could have put some reserved bits in the original pickle
> format for datetime back when it was first defined, or even just allowed
> passing in a longer string for future extension purposes. That you
> didn't makes me wonder just where you're finding the space to put the
> fold bit.

By exploiting the currently-always-0 first bit in the "minutes" byte.
See https://www.python.org/dev/peps/pep-0495/#pickles

It might be useful to read PEP 495 before commenting on it ;-)

>> It's not so much a "good idea" as that it's the only idea consistent
>> with Python's "naive time" model.  Folds and gaps don't exist in naive
>> time.  Indeed, the _concept_ of "time zone" doesn't really exist in
>> naive time.  There's _inherent_ tension between the naive time model
>> and the way multi-offset time zones actually behave.  So it goes.
> 
> But why does it need to be consistent? You can't compare naive datetimes
> with aware ones. If you want to sort/bisect a list of datetimes, they
> have to either all be naive or all be aware. So when we're talking about
> how ordering works, we're fundamentally talking about how it works for
> aware datetimes.

What you're missing (and I was missing too, before going around in some
lengthy earlier threads on this mailing list, which you may -- or may
not -- find it worth your time to read) is that even "aware datetimes"
in Python's datetime library always operate in "naive local clock time"
for whatever timezone they are in; they aren't just alternate notations
for the corresponding UTC time.

This is why if you add timedelta(hours=24) to datetime(2014, 11, 2, 12,
tzinfo=Eastern), you get datetime(2014, 11, 3, 12, tzinfo=Eastern), even
though the difference between those two datetimes in UTC is 25 hours,
not 24.

In order to stay consistent with that "naive local clock time" model,
all operations within a time zone must ignore the `fold` value. The
`fold` value really doesn't exist at all in the naive clock time model,
it's only tracked as a convenience for correct round-tripping. This
implies that 1:30am fold=0 and 1:30am fold=1 are equal, and also that
1:20am fold=1 is "earlier" than 1:40am fold=0 (as long as you stay
within the naive clock time model -- if you don't want to, you should
convert to UTC).

You may want to rail against that model. I (and some others) already
did. You can go back in the archives here and read our efforts. Perhaps
you'll have better luck if you try; I doubt it. But given that model,
this is the only approach that makes sense.

And you can get the same work done in that model. If you want to operate
on the physical-time timeline, just always operate in UTC internally and
only translate to "aware datetimes" at display time. That's what you
probably should be doing anyway.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150914/382234db/attachment.sig>