I have considered exactly the same thing (using fold for leap seconds). My post was playful exploration and trying to find out what it would actually *mean*. Is it just a convenient place to cram that extra bit? Are these real folds? If they are, are they folds in exactly the same sense? I think I have reached some interesting conclusions from this thought experiment. PEP 495 defines folds for disambiguating “local” time. The “non local” time is presumably UTC and does not require such disambiguation. Except that it does. UTC has folds called leap seconds. So what I envision is extending this notion of localness to multiple levels. The “least local” time is TAI or time scales that differs from it by some constant. UTC is “more local” than TAI. It applies to our local planet Earth whose rate of rotation varies continuously. The real local Earth time is UT1 but UTC is a convenient approximation of UT1 that is quantized to 1 second steps. The “most local” time is civil time, as implemented by various national time zones. In the past, time was often reckoned from local sunrise (in Addis Ababa airport departure times still are, much to the confusion of non locals). Daylight savings could be considered a strange approximation of local sunrise, quantized to a 1 hour step. So we have a three tier hierarchy of localness. The definition is cumulative: civil time is defined by UTC and therefore inherits leap seconds. Do we need two separate fold bits to represent this unambiguously? Leap seconds occur in winter and summer, while DST switches on spring and autumn. The big switch in the Samoa time zone was close, but it was still a full day away from any potential leap second. I haven’t checked the entire IANA database but I think we are lucky and can safely disambiguate the two uses of this bit. Conversion between two local time zones may be done via UTC as an intermediate. Does it make any difference if this intermediate is taken all the way to TAI and back? The only difference is that the conversion will now preserve a leap second. This can be easily simulated without actually going to TAI. A more permissive implementation may verify that this is the last second of December or June without actually verifying that there is an official leap seconds at that time. All local civil time zones are defined by reference to UTC. Even Caesia Standard Time can be defined by reference to UTC. The three levels of localness can still maintain the use of the middle layer (UTC) as reference. There is no need for calculating an actual TAI count of seconds unless explicitly requested. An initial implementation may only support leap seconds for time arithmetic, not live clocks. The only way to get a UTC timestamp with fold=1 (other than setting it explicitly) would be to convert a TAI timestamp to UTC. Directly obtained UTC timestamps will keep doing whatever the local platform does during and around a leap second. A reliable source of TAI (or UTC+correct leap/fold flag) is not so easy to obtain and verify. What do you do if it is not consistent with time_t? CLOCK_TAI defaults to being equal to CLOCK_REALTIME. A comprehensive solution may actually be outside the scope of the Python library. The “right” timezones are a clever and compelling idea, but it means that *everything* must be converted through the timezone logic - including converting time_t to UTC. There is just too much code around that assumes time_t is already UTC - and that days have exactly 86400 SI seconds. These assumptions are obviously incompatible, but at least the one about time_t being UTC breaks only momentarily and infrequently, while using the “right” timezones requires it to be broken it all the time. Oren Oren On Monday, 28 November 2016, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Sun, Nov 27, 2016 at 12:44 PM, Oren Tirosh <orent@hishome.net <javascript:_e(%7B%7D,'cvml','orent@hishome.net');>> wrote:
The "gaps" in conversion from Caesia Standard Time to UTC all correspond to UTC Leap Seconds. It is well-known that gaps at one end of a timezone conversion correspond to "folds" at the other end - a period that occurs twice. Until recently, there was no support for folds in the datetime library of the Python language (Caesians are avid Pythonistas). Now that PEP495 has been implemented they are keen to check how well the datetime library interoperates with their unusual (yet completely well-formed and valid) time zone definition.
Can you help them?
I am not sure how serious your post is, but I've been toying with an idea that UTC y-m-d:23:59:*60* should be represented in Python as datetime(y, m, d, 23, 59, *59*, fold=*1*). This would allow one to implement Olson's "right" timezones - a timekeeping scheme where time_t is at a fixed offset of TAI and UTC has a second-wide "fold" on every positive leap second.