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

[Tim Peters]

[Tim]
>> So, on your own machine, whenever daylight time starts or ends, you
>> manually change your TZ environment variable to specify the newly
>> appropriate eternally-fixed-offset zone?  Of course not.

[Random832 <random832 at fastmail.com>]
> No, but the hybrid zone isn't what gets attached to the individual
> struct tm value when you convert a time from utc (or from a POSIX
> timestamp) to a timezone local value. A single fixed utc offset is
> (along with the name and, yes, isdst flag).

You're assuming much more than POSIX - and the ISO C standard -
requirs.  My description was quite explicitly about how POSIX has done
it all along.  tm_gmtoff and tm_zone are extensions to the standards,
introduced (IIRC) by BSD.  Portable code (including Python's
implementation) can't assume they're available.


> And pytz doesn't involve manually changing anything, it involves (as
> best it can) automatically applying the value to attach to each
> individual datetime value.

.normalize() is a manual step.  It doesn't invoke itself by magic
(although I believe Stuart would like Python to add internal hooks so
pytz _could_ get it invoked by magic).


>> A datetime object is the Python spelling of a C struct tm, but never
>> included the tm_isdst flag.

> And no-one behind this proposal seems to be contemplating adding an
> equivalent to tm_gmtoff,

It was off the table because, for backward compatibility, we need to
mess with the pickle format as little as possible.  It's vital that
datetimes obtained from old pickles continue to work fine, and that
pickles obtained from new datetime objects work fine when loaded by
older Pythons unless they actually require the new fold=1 possibility.

> despite that it would serve the same disambiguation purpose and
> make it much cheaper to maintain global invariants like a sort order
> according to the UTC value

It would be nice to have!  .utcoffset() is an expensive operation
as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
instead.


> (No, I don't *care* how that's not how it's defined,

?  How what is defined?:


> it is *in fact* true for the UTC value that you will ever actually get
> from converting the values to UTC *today*, and it's the only total
> ordering that actually makes any sense)

Well, you lost me there.  In a post-495 world, conversion to UTC will
work correctly in all cases.  It cannot today.;