On 16 February 2015 at 00:28, Paul Ganssle <pganssle@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@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