[Datetime-SIG] PEP-431/495

Tim Peters tim.peters at gmail.com
Sun Aug 23 02:37:11 CEST 2015


[Alexander Belopolsky]
> Please keep hammering.  If we add an additional member to the datetime
> objects, I want the new API to be good for the next 20 years and not just
> wet the appetite for adding more and more with every Python release.  For
> example, if anyone can find a place on Earth where 01:30 AM was repeated 3
> times in one day - I will be all for changing ltdf type from boolean to
> integer.  Not because I think it is important to support that one exotic
> event, but because if that was done once somewhere it will certainly be done
> again somewhere else.

If we want to be future-proof, I think ltdf needs to change from a
flag to a 64-bit unsigned int ;-)

What _will_ happen is that computer programmers will refuse to support
"unreasonable" (to them) changing realities, until the current
generation of programmers dies off.  After all, "POSIX time" is just a
mathematical abstraction that ceased being connected directly to civil
time just a few years after POSIX defined it (when the Change That
Must Not Be Named was added to the definition of UTC).  The way it's
still defended, you'd think Guido invented it ;-)

So this is what happens:  the long-overdue massive earthquake on the
US East Coast finally knocks New York off the North American
continent, and sends it drifting east.  After coasting about 1000
miles.east, it stops.  Mayor De Blasio will take a brave political
stand, and be re-elected on a platform that includes switching New New
York to a more appropriate time zone, in the coming fall when DST ends
too.  But city IT Professionals will tell him they can't manage
shifting two hours in one jump.  So, when DST ends at 2AM EDT, the
clock will jump back to 1AM EST.  Then when it hits 2AM EST, it will
jump back to 1AM NEWNEWYORKST.

Python's 2-state flag will be inadequate to distinguish among the
3-way ambiguities.  Timezone wonks will scream.  Nobody else will
care.  Exactly the same kind of scandal as when zoneinfo incorrectly
claimed that America/Whitehorse switched from UTC-9 to UTC-8 on
1966-07-01 instead of the correct 1967-05-28.

Although, to be fair, I'm pretty sure it will take more than 20 years
for New New York to drift that far east, so a single bit should be
"good for the next 20 years" after all ;-)


More information about the Datetime-SIG mailing list