[bxparks]

Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time

During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears (or alternatively, the given POSIX-second lasts 0 UTC-seconds).

On my Ubuntu box, the `date +%s` command prints the number of POSIX seconds since 1970-01-01, not the number of UTC seconds since 1970-01-01. To get the number of UTC seconds, we must add the number of intervening leap seconds since 1970-01-01.

I get a headache every time I have to think about this.

[nullc]

The often made and only technically true claim that posix/unix time "ignores leap seconds" is actually a major source of leapsecond handling bugs, because it makes people think that posix time is TAI (with some offset). Instead posix time is UTC with some seconds that have unusual lengths (0 or two SI seconds, as you note).

When you want to know the number of SI seconds between two dates in either posix or UTC you need an accurate table of past leapseconds. If you want to compute TAI from posix or UTC you need an accurate table of leap seconds that your UTC clock has applied (which may not be the same as the table of leap seconds, since you might have missed the most recent one!).

[jillesvangurp]

Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not precise enough. Without syncing they'd be drifting apart many seconds within days/weeks probably.

That's also why the leap second correction is not a big deal because it just happens when computers sync. A few seconds correction is just a routine correction. Happens all the time.

[nullc]

> That's also why the leap second correction is not a big deal because it just happens when computers sync. A few seconds correction is just a routine correction. Happens all the time.

That may be how things work for someone's word processor appliance, but on Linux/etc. NTPD or chrony continually estimate your local clocks drift and compensate for it and change their polling rate as a function of uncertainty (e.g. from temperature effects). They save the estimate drift rate in a persistent file on disk (chrony can optionally compensate for temperature effects; see tempcomp in the manpage).

On some random supermicro server here the crhony drift file says that the clock is slow by -33.208515 parts per million (not atypical for a non-temp-compensated oscillator), with an uncertainty of 0.031571 in that measurement.

As a result other than leap seconds there is no discontinuity in your local time, no few seconds correction that you suggest. Just a continuous clock that is steered smoothly to agree with UTC.

This is really important when you're dealing with subsecond events that must be synchronized among distributed systems.

Hosts on my network here that have no special handling of their time keeping will have time that agrees with each other within +/- 100 microseconds (and with UTC, for that matter, thanks to the local gps disciplined clock). Without a local GPS clock you'll get extra uncertainty from network path asymmetry, but that uncertainty is limited to the round trip time... which is a lot less than 1s if your network is at all usable interactively. :)

A 1 second jump would be gargantuan.

For many applications +/- 1 second is fine. But for others it isn't fine. Modern computers with network time available should have no problem being accurate much much better than 1 second.

[zokier]

The reason why POSIX time ignores leap seconds was that it was considered simpler for userspace if you can do things like `time() % 86400` to get the time of day etc without needing to worry about leap seconds, essentially allowing userspace to be ignorant of leap seconds.

[jeroenhd]

This is also why I think it's silly people make such a big deal out of leap seconds. Yes, to the programmers it would be great if time were to flow uniformly, but it doesn't, and it doesn't even stay consistent on your computer. Your time may go back and forth several seconds depending on your RTC and its conditions and leap seconds should be treated the same.