Leaping seconds and looping servers

Posted Jul 5, 2012 1:46 UTC (Thu) by wahern (subscriber, #37304)
In reply to: Leaping seconds and looping servers by paulj
Parent article: Leaping seconds and looping servers

That's why I used the scare quotes. "Seconds" are the units the computer stores, but 7 months later nobody cares how many seconds have passed. They care how many months, days, hours and minutes have passed.

The SI second is different than the second that most people care about. When people speak of seconds, they're usually speaking in terms of remainders of a minute, which are remainders of an hour, which are remainders of a day. People chunk time, the same way we chunk everything else for our memory.

The day is a fuzzy unit, and equivocating day units with second units is always going to fail. So you can either redefine the day (as industry wants to do by changing UTC), or you can redefine the second, as POSIX effectively does. Or, I suppose, software could stop using second units for storage, and use expanded date-time descriptions.

I say that POSIX time is beautiful because it, rather accidentally, codified a redefinition of the second. And it turns out that it works very well for many use cases, both where you produce output directly for human consumption, or for inputting into algorithms which collaterally produce output for human consumption. It's a manifestation of the worse-is-better principle, where you sacrifice a quality like elapsed second precision for other qualities--simplicity and, depending on the context, robustness. However, it's just horrible for cases that rely on precise SI seconds, and it's clearly not simplistic from the perspective of the kernel.

Leaping seconds and looping servers

Posted Jul 5, 2012 4:53 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

How about we use GUIDs and distribute copies of the official list that uniquely identifies every second past or future.

8-) kidding of course.

Leaping seconds and looping servers

Posted Jul 12, 2012 13:41 UTC (Thu) by njs (subscriber, #40338) [Link]

Well. Except. It turns out that to get a really precise TAI timestamp, what you do is:

1) When the event occurs, get a timestamp from the nearest convenient national lab atomic clock.

2) Wait a few weeks while the different national labs compare their clock's relative drift rates over the last period, pick some sort of average as the "real TAI time", and publish tables mapping from what their clock actually did to this consensus clock that doesn't exist.

3) Look up the timestamp you got in step 1 in this table.

It's hard to make jokes about time...

Leaping seconds and looping servers

Posted Jul 5, 2012 5:20 UTC (Thu) by butlerm (subscriber, #13312) [Link]

POSIX time is great for most of the uses to which it is put. There is no need to get rid of it any time soon, nor could we. It just shouldn't be used as the basis of anything requiring sub-second accuracy, linearity, or precision.

This failure in particular would not have occurred if the kernel and all the pertinent applications used a reliable time base do timing with, instead of trying to derive reliable timing from a time base with all the stability of a drunken sailor.

Leaping seconds and looping servers

Posted Jul 5, 2012 9:40 UTC (Thu) by dgm (subscriber, #49227) [Link] (5 responses)

> I say that POSIX time is beautiful because it, rather accidentally, codified a redefinition of the second.

Forcing the 1 day=86400 seconds stuff was one of the worst ideas ever, and we're still paying the consequences. Effectively it means you are really counting days, not seconds, but a day is not a precisely defined unit. Had they just kept as a simple count of seconds, that would have been useful and simple. And less error prone.

I sincerely don't get how can you say this is beautiful.

Leaping seconds and looping servers

Posted Jul 6, 2012 17:14 UTC (Fri) by giraffedata (guest, #1954) [Link] (4 responses)

Forcing the 1 day=86400 seconds stuff was one of the worst ideas ever ... Had they just kept as a simple count of seconds, that would have been useful and simple. And less error prone.

You might be able to argue that in 2012 it would be better for POSIX to specify a simple count of seconds, but if you look at how the world was when that time format was invented, there just can't be any question that not including leap seconds in the count was the right thing to do.

Users of computers want traditional UTC-style year-month-day etc. datetimes. To convert from a simple count of seconds to that requires not only significantly more code to be written but some way to know when the leap seconds were. A file, a manual maintenance procedure, or a global computer network, all of which were simply not practical enough to meet the timekeeping requirements of the users.

Most of the present discussion isn't about whether the POSIX standard should be a simple count of seconds, but whether the kernel's time base should be. POSIX doesn't say how anyone has to keep time; it just says how it gets communicated. Either way, some users are going to be adjusting for leap seconds; some adding them, others removing them.

Leaping seconds and looping servers

Posted Jul 9, 2012 11:33 UTC (Mon) by dgm (subscriber, #49227) [Link] (3 responses)

> there just can't be any question that not including leap seconds in the count was the right thing to do.

It was a mistake, and no amount of historic excuses can make it a right decision. I never was the right thing to do, neither is it now.

> Users of computers want traditional UTC-style year-month-day etc.

Users don't talk to the kernel, nor with the system libraries. They talk to applications. And by the way, users really don't care about UTC, 99% of the time they want the time their watch says it is. Until that's not enough, and then what they want is an _unambiguous_ moment in time. Anything between those extremes is completely useless.

> To convert from a simple count of seconds to that requires not only significantly more code to be written but some way to know when the leap seconds were.

What exactly solved forcing the duration of the day? Nothing, everything is exactly as complex as it was, but now you have that "fictional" day which is different from what users need. And you still need complex time handling code because there are such niceties as timezones, local calendars, different week conventions, and even time dilation!

> Most of the present discussion isn't about whether the POSIX standard should be a simple count of seconds, but whether the kernel's time base should be.

The mere fact that there's a discussion is a sign that people are not sufficiently aware of past mistakes. We should be raising awareness of this, with the goal of avoiding repeating them. The Kernel should just count time in the most unambiguous way it can, and let applications handle the presentation.

> POSIX doesn't say how anyone has to keep time; it just says how it gets communicated.

An application cannot give the user an unambiguous moment in time if all it can get from POSIX is an ambiguous representation. That is the crux of the matter.

Leaping seconds and looping servers

Posted Jul 9, 2012 15:57 UTC (Mon) by giraffedata (guest, #1954) [Link] (2 responses)

Users of computers want traditional UTC-style year-month-day etc.
users really don't care about UTC, 99% of the time they want the time their watch says it is.

Every watch in the world displays traditional UTC-style year-month-day etc. My point is that POSIX time makes it more practical for a computer to display that than a straight seconds-since epoch time format would. Or are you referring to the watch being inaccurate?

And you still need complex time handling code because there are such niceties as timezones, local calendars, different week conventions, and even time dilation!

Except for the time dilation, which history proves you don't need in your time handling code, those are all simpler to handle than leap seconds. Asking the computer to understand leap seconds is asking for a whole other level of computation. The most significant part of that is knowing when the leap seconds are.

What exactly is solved forcing the duration of the day?

At the risk of being repetitive, it allows for practical calculation of UTC-style, wristwatch-style datetimes. Also for calculating differences in the larger units such as hours and days (when a computer user says "3 days after 10:00 Wednesday," he normally means 10:00 Thursday, not 86400*3 seconds after 10:00 Wednesday).

It also causes or fails to solve some other problems. The only question is which problems are greater?

By the way, if unambiguous datetimes were seen as a problem worth solving in the days that POSIX was invented, I think the proper solution would have been to go with the same "seconds since epoch not counting leap seconds" and then have a separate bit saying "leap second" that the folks who need to distinguish between 23:59:59 and 23:59:60 could use. Practically computable datetimes are that important.

Leaping seconds and looping servers

Posted Jul 9, 2012 18:44 UTC (Mon) by dark (guest, #8483) [Link] (1 responses)

Ah, but consider the user who says "3 days after Friday 10:00". Presumably that user wants "Monday 10:00", and not "Monday 9:00, 10:00 or 11:00 depending on whether there is a DST transition this weekend". So yeah, you can't use 86400*n anyway. Unless you want to mishandle DST, which is the option chosen by the vast majority of applications :)

Leaping seconds and looping servers

Posted Jul 9, 2012 23:16 UTC (Mon) by dgm (subscriber, #49227) [Link]

Indeed. 1 day = 86400 seconds is a computation that was broken from the start. It wasn't working back in the day POSIX was defined, and of course, things could only go downhill from there.

As a bunch of others have pointed out, leap seconds are very similar in essence to timezones -or any other oddity of civil time- in that they are _arbitrary_. They really belong in the code that has no choice but to handle them: the system libraries (glibc for modern Linux distros).