'Leap Seconds' May Be Eliminated From UTC

angry tapir writes "Sparking a fresh round of debate over an ongoing issue in time-keeping circles, the International Telecommunications Union is considering eliminating leap seconds from the time scale used by most computer systems, Coordinated Universal Time (UTC). Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."

Comments

Oracle

[Anonymous Coward]

Perhaps Oracle should concentrate more on making their software reliable, and less on lawsuits.

From what I recall Digital VMS didn't have that problem, and even had no problems migrating an always on system over different processors, and keeping the cluster running over more than 15 years. One second and Oracle crashes.

It's a pity which of those companies survived.

The real problem is using seconds for everything

[Terje Mathisen]

I've worked with NTP for nearly 20 years now, and the leap second adjustments isn't a real problem.

The crux of the matter is that we've insisted (in both Unix and Windows) on measuring calendar events in seconds:

The proper solution is to use Julian Day Number as the basic unit for calendars and (SI) seconds for any kind of short-term measurement. If you really need second/sub-second precision for long-term (multi-day) measurements, then you have to accept that the conversion is not just a matter of multiplying/dividing by 86400.

Calendar appointments and similar things should be defined by day number and some form of fractional day, not SI seconds.

NTP is somewhat to blame though: Even though it has full support for leap second handling (both adding and subtracting), the core of the protocol pretends that UTC seconds (without leap adjustments) is sufficient, i.e. NTP timestamps are defined to be in a 64-bit fixed-point format with 32 bits counting seconds since 1900-01-01 and 32 bit for the fractional seconds, i.e. sufficient to handle a 136-year block with a quarter of a ns resolution.

http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap

This causes small hiccups for an hour or so after each adjustment: The primary servers and those that either have a leap-second aware source or a cluefull operator keep in sync throughout the adjustment, while the remainder will slowly detect that their local clocks seems to be a full second off. Since this is way more than the default +/- 128 ms which NTP is willing to handle with gradual adjustments, NTPD will instead step the clock (backwards for an added leap second) and restart the protocol engine, after discarding all history.

Modern versions of NTP have been rewritten to use a vote between all otherwise good servers: If a majority claim that there will be a leap second at the end of the current day, then the local deamon will believe them, and thereby stay in sync even during the actual leap second itself.

Terje