Hacker News Reader

Comment by duiker101 | Hacker News Reader

2012. and we still have problems keeping track of time. This is both fascinating and scary.

P.S. for people wanting to know more this video is simple to understand but really amazing http://www.youtube.com/watch?v=xX96xng7sAE

View on HN

Maybe we always will have problems?

It seems to be the unique class of bug that not only is it easy to forget to test, and won't ever show up until a particular date... but then affects everyone!

I can't think of any other kind of bug that never shows up ever, but then affects everyone. Rare bugs tend to stay rare, common bugs tend to get caught before they affect everyone... this is the exception.

From discussion of this same issue in prior threads, my takeaway was

(a) it's really not at all difficult to handle leap seconds, but

(b) the POSIX standard specifically disallows them, by specifying that a day must contain exactly 86400 seconds. (Analogously, imagine if leap days occurred as normal, but a "year" by definition contained exactly 365 days.)

The existence of leap seconds means that it's not possible to simultaneously have (1) system time representing the number of seconds since the epoch, and (2) system time equal to (86400 * number_of_days_since_epoch) + seconds_elapsed_today, and all the proposed methods of dealing with the problem involve preserving (2), which seems worthless to me, and throwing away (1), which I would have thought was a better model.

edit: actual system times may be in units other than seconds, but the point remains

It's harder than leap days, because leap seconds aren't inserted on a regular schedule. Leap days follow a predictable pattern of insertion. Leap seconds are inserted whenever the IERS decides to insert them.

The problem of leap seconds is therefore closer to that of time zone definitions -- which are a total mess, because they depend on keeping rapidly changing system tables up to date. I can see why people don't relish the idea of requiring similar tables just to keep system time accurate.

How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?

It seems like we already have a much bigger lead time for notification than we could possibly need.

> I can see why people don't relish the idea of requiring similar tables just to keep system time accurate.

But the 'solution' we're using now is to make system time less accurate, not more accurate. Accurate would be if leap seconds incremented the system clock like normal seconds do. If the accuracy you're worried about is displaying a clock time rather than time since the epoch, you already need a time zone to do that.

"How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?"

I am not an expert, but as far as I know the most automated solutions are doing it via NTP, which just resets the second, then relies on clock drift to bring everything back into synch. Otherwise, I think your only option is to keep the timezone packages up-to-date (which is a non-trivial task for large deployments). A quick search found this:

http://www.novell.com/support/kb/doc.php?id=7001865

"But the 'solution' we're using now is to make system time less accurate, not more accurate."

Yeah, I'm not disputing this. I'm just saying that preserving the assumption that "day == 86400 seconds" probably breaks less code than the alternative. NTP messes with the notion of seconds-since-epoch anyway, so we know that single-second variations in unix time aren't automatically deadly to most unix software.

NTP sends a special message to the kernel (using adjtimex), that boils down to: today you will insert a leap second. This isn't the same as clock drift, which gets smoothed out, it means a minute with a 60th second (in UTC) or with the 59th second happening twice (in POSIX). NTP servers need a leap second table ( http://support.ntp.org/bin/view/Support/ConfiguringNTP#Secti.... ), but most other systems only need to know the current delta between POSIX and TAI, and manage without a leap table.

Interesting analysis. Preserving (2) means that systems that don't handle leap seconds (or don't have a leap seconds table updated in the last six months) have a POSIX time at most 1 second away from systems that do. Dropping (2) would mean a more complicated formula to convert system times to times of day, but it would also make the failures and missing leap tables immediately noticeable, rather than a one-in-a-few-years event. Which would have made it the better choice; bugs encountered during development are easily handled, bugs that happen years later on production systems are inconvenient.

A clever solution would be keeping an internal time and generating POSIX times (and human friendly times) as needed. This way, leap seconds will never touch true system time.

Its... worse. We can track time so easily and so well that we decided to screw it up.

2012 and we still don't really know what time is. The fact that we can keep track of it, even with all the problems, is quite amazing.

Physics perfectly well knows what time is. This is an issue with keeping track of time in terms of seconds, minutes, hours and days, and has nothing to do with not knowing what time is.

What is time, other than a state in which net entropy within a closed system increases (which is already a definition abstract enough that it almost misses the point)?

That's not really a definition of time, just a way to postulate its direction. Time as a physical unit has been decreed to be the rate of decay of a certain Cesium atom; i.e., a fixed regular interval, whereas the increase of entropy varies from moment to moment. E.g. right now I'm typing and before I wasn't, that doesn't mean time is going ever so slightly faster because of that ...

>rate [sic] of decay of a certain Cesium atom //

That is time in the same way that leaves moving on a tree is wind.

The instance of the radioactive decay indicates the defined period of time has passed within the local frame of reference. That tells us very little useful about time itself.

I wasn't making a philosophical statement, I specifically qualified it by saying "as a physical unit." That's still nowhere near precise enough, but I only meant to point out that we typically don't conceive of time as an emergent property of physical processes (i.e., entropy change), but as a local property of a very specific atom, such that time passes at a constant rate, if only because we choose to define it that way. "Telling something about time itself" sounds like a philosophical question which I fear has no definite answer.

Decay of nuclei is a completely random process, and you really don't want to use it to define a time-scale.

What you had in mind is the SI-definition of the second, which reads (http://www.bipm.org/en/si/si_brochure/chapter2/2-1/second.ht...):

  """
     The second is the duration of 9 192 631 770 periods
     of the radiation corresponding to the transition
     between the two hyperfine levels of the ground state
     of the caesium 133 atom.
  """

The details of this effect are a little more complicated, but it boils down to the fact that you can measure the "angular momentum" of your nuclei when you have them pass through a non-uniform magnetic field. Particles in the one state are deflected differently than particles in the other state. And when you irradiate a particle beam in the F=0 state with the right frequency (9.2 GHz) you can very efficiently swap many particles over to the F=1 state. By adjusting your frequency sufficiently to find the maximum rate of flips, you can can tune for the exact 9'192'631'770 Hz.

The cesium particles have not decayed, in principle you could run forever on a certain supply of atoms... even though in practice a Cs-beam is produced on one side, at a hot filament, and dumped to the other side of the clock after passed through the apparatus that performs the steps described above. They will be disposed of when the lifetime of the beam-tube is reached (typically 10 years or so with a few grams of cesium inside).

In this case, i believe we created a problem we did not have. Leap seconds is a dubious construct from the start, problematic with computers or space travel. We have added only 25 since 1972. Their unpredictability means they will be forever a problem with computing. We should either quit the whole idea or in the worst case allow them only every 25 years or so.

Edit: In fact there is strong indication that they may be abolished: http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish...

Nice video but what if we used Sidereal time? (i.e., star time, which ignores the earth's rotation around its axis).

Reply on news.ycombinator.com