[Datetime-SIG] A tale of gaps, folds and leap seconds.

[Oren Tirosh]

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 at gmail.com> wrote:

>
> On Sun, Nov 27, 2016 at 12:44 PM, Oren Tirosh <orent at hishome.net
> <javascript:_e(%7B%7D,'cvml','orent at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20161130/5cc54eaf/attachment.html>