[mikeash]

Why aren't leap seconds treated as a time zone change, like a daylight saving time transition? Keep the underlying clock counting the number of actual seconds since midnight, January 1st, 1970 (or whatever your epoch of choice is) and just add one more second into the offset to local time. Is there some big problem with this approach I haven't thought of, or is there just too much history with doing it the other way to change now?

[Someone1234]

I don't understand why either. Counting up from 1/1/1970 and then making adjustments for rendering only seems like a simple, reliable, and time tested solution.

I guess people don't want a database of leap seconds and a lookup each time time is rendered, but ultimately it seems like the best solution which is least likely to break things.

[Scramblejams]

Yeah. I'd like to see us all set our hardware clocks to TAI and everything else comes from the time zone files. It won't solve everything because lots of protocols have broken notions of time, but at least we could all agree on what the hardware time is supposed to mean and there would be no worry about leap seconds at that level.

[danielweber]

The nice thing about time standards is that there are so many to choose from!

One drawback of your approach is that I can't just see if a time = 0 mod 60 to check if we are on a minute boundary.

Your way is what is used by the GPS network, IIRC, and it works for them, so there you go.

[mikeash]

If your dates and times and locations vary enough, you already can't do a mod 60 check on UTC to detect a minute boundary, as various historical time zones include seconds-level offsets from UTC. For example, US cities were on local solar time until the latter part of the 19th century, and the changeover to uniform time zones involved lots of seconds-level offsets. Interesting stories here:

http://historymatters.gmu.edu/d/5748

[Dylan16807]

I don't think anything to that resolution is in any time zone database, so you would be using a custom system anyway.

[mikeash]

I just downloaded the standard ones from: https://www.iana.org/time-zones

It appears to have this stuff down to the second. For example:

    # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
    Zone America/New_York	-4:56:02 -	LMT	1883 Nov 18 12:03:58

    # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
    Zone America/Chicago	-5:50:36 -	LMT	1883 Nov 18 12:09:24

Although this won't really be accurate, because it doesn't have every single city. The New_York zone covers the whole eastern time zone even though all the cities in that zone would have been different before 1883. But it is in the database, even if it's not quite right for anything outside of the named cities.

[Dylan16807]

Well that's a mess. Wrong data is worse than missing data for something like this...

[bashinator]

Many (most?) important computer systems use UTC precisely to avoid time changes like the DST transition. Just one example that comes to mind is that DST can cause important cron jobs to repeat, or not occur at all.

[mikeash]

Right, which is why it seems like the obvious thing to use TAI as the underlying base time in a computer system, and have UTC be just another time zone offset on top of that, so you don't have to deal with leap seconds either.

[bashinator]

Ah, I see what you mean - akin to the OS clock being in UTC, while a user sets their account $TZ environment to their local time.

[mikeash]

Exactly. The underlying clock would store actual seconds since 1970, and when you request UTC it would add the current leap second offset. Which is more or less how GPS does it already, for an actual working example.