[tz] An outline of a possible solution for sensible leap-second support.

Tim Parenti tim at timtimeonline.com
Mon Feb 16 16:51:52 UTC 2015


On 16 February 2015 at 00:28, Paul Ganssle <pganssle at gmail.com> wrote:

> Have there actually been any time zones that are not an even multiple of a
> whole minute since the advent of leap seconds? The only non whole minute
> time zone I know about is Dublin Mean Time, which hasn't been used since
> 1916.


If I recall correctly, Africa/Monrovia is the only zone in the main files
which has had an offset that is not an integer number of minutes at any
point since 1970 (it was -0:44:30 until 1972-05).  UTC was introduced in
1972, with the first leap second (as we know it today) coming at the end of
1972-06-30.  So, no; this isn't a real concern in any existing zones.

On 15 February 2015 at 09:12, <random832 at fastmail.us> wrote:

> Also, general question: is there any standard on how leap seconds are to
> be handled in timezones that have an offset that is not a multiple of
> one whole minute? What does tzcode do now?
>

In the interest of... well, interest ;) ...let's find out!  Adding:
Zone Test/Foo 0:00:30 - FooST
to the data, and installing with make right_only, we can perform a zdump:

$ zdump -c 2015,2016 -v Etc/UTC Asia/Tokyo Test/Foo
...
Etc/UTC     Tue Jun 30 23:59:60 2015 UT = Tue Jun 30 23:59:60 2015 UTC
isdst=0 gmtoff=0
Etc/UTC     Wed Jul  1 00:00:00 2015 UT = Wed Jul  1 00:00:00 2015 UTC
isdst=0 gmtoff=0
...
Asia/Tokyo  Tue Jun 30 23:59:60 2015 UT = Wed Jul  1 08:59:60 2015 JST
isdst=0 gmtoff=32400
Asia/Tokyo  Wed Jul  1 00:00:00 2015 UT = Wed Jul  1 09:00:00 2015 JST
isdst=0 gmtoff=32400
...
Test/Foo    Tue Jun 30 23:59:60 2015 UT = Wed Jul  1 00:00:30 2015 FooST
isdst=0 gmtoff=30
Test/Foo    Wed Jul  1 00:00:00 2015 UT = Wed Jul  1 00:00:30 2015 FooST
isdst=0 gmtoff=30
...

So, it looks like it just keeps a constant offset (which is quite
reasonable), even though in such cases it would explicitly require counting
the same second twice (which is not quite so reasonable).

I recalled seeing a proposed solution which took the opposite approach
earlier on this list, which was to forsake the constant offset in favor of
counting as normal, before "applying" the leap second at the end of the
"local minute" which contained the UTC leap second.  Upon further
investigation, it seems that suggestion came from you, random832!
http://mm.icann.org/pipermail/tz/2013-September/020155.html

So in terms of behavior for the purposes of documentation, those are the
two options.  But, again, I doubt this is going to matter for any practical
purposes anytime soon, so I would expect tzcode will likely stay as it is
with respect to this matter.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150216/648f58d8/attachment-0001.html>


More information about the tz mailing list