Leaping seconds and looping servers

Posted Jul 3, 2012 19:54 UTC (Tue) by paulj (subscriber, #341)
In reply to: Leaping seconds and looping servers by drag
Parent article: Leaping seconds and looping servers

For whom would it matter, exactly?

Leaping seconds and looping servers

Posted Jul 3, 2012 19:59 UTC (Tue) by drag (guest, #31333) [Link] (14 responses)

People that need to keep accurate time keeping, I suppose.

I expect that for a whole host of applications having a second that is randomly different from all other seconds would be irritating. Anything dealing with automation on a assembly line would probably be irritated to know that their devices are going to have to deal with time units that are shifting goal posts. Avionics was mentioned above as well as a couple other things that I won't bother repeating.

The whole point of the leap second is to keep a second a second. When a second is not a second then what do you do to deal with that?

Leaping seconds and looping servers

Posted Jul 3, 2012 20:08 UTC (Tue) by paulj (subscriber, #341) [Link] (13 responses)

For control functionality that is compromised by 10% inaccuracy, surely they should be using monotonic timers?

For timestamps for record keeping, with similar requirements, surely they should be using epoch-based kernel interfaces, and doing any remaining formatting to and conversion for calendar times in userspace?

Leaping seconds and looping servers

Posted Jul 3, 2012 21:03 UTC (Tue) by drag (guest, #31333) [Link] (12 responses)

> surely they should be using epoch-based kernel interfaces

Well if I was following the discussion correctly it's those 'epoch-based kernel interfaces' that are the things being 'smeared'.

Besides that,

If it was up to me all the programs I use would only see time in epoch UTC. That would be the only time supported by anything. It's the userspace's responsibility to present time in a human-readable format. Unfortunately that is not how people do things.

Leaping seconds and looping servers

Posted Jul 3, 2012 23:53 UTC (Tue) by xman (subscriber, #46972) [Link] (4 responses)

The kernel's use of UTC time was why ntpd had to do what it did, which exposed the faulty logic.

TAI is the way to go.

Leaping seconds and looping servers

Posted Jul 4, 2012 3:28 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

Does anybody actually use TAI for anything?

As far as scientific time keeping it's already been found to be fundamentally flawed due to the fact that they didn't take the effect of gravity into it. and is probably going to be replaced by something else eventually that is adjusted for altitude.

Leaping seconds and looping servers

Posted Jul 4, 2012 13:26 UTC (Wed) by andreasb (guest, #80258) [Link]

Going by what's on the Wikipedia page, it has been corrected for altitude (normalized to mean sea level) since 1/1/1977. The former uncorrected TAI got the new name EAL.

Leaping seconds and looping servers

Posted Jul 4, 2012 18:32 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> Does anybody actually use TAI for anything?

GPS does. The GPS timestamp is TAI with a fixed offset.

Leaping seconds and looping servers

Posted Jul 17, 2012 17:59 UTC (Tue) by Baylink (guest, #755) [Link]

No; that's factually incorrect, I'm afraid.

The problem here is not the *choice of timescale*: UTC is monotonic even over leap seconds; 58, 59, 60, 00.

The *problem* is that the kernel isn't following UTC *either*; not if it's ticking backwards. It's that *ticking backwards* part that is the problem, and I've yet to see a truly compelling reason why it should do so.

Leaping seconds and looping servers

Posted Jul 4, 2012 11:49 UTC (Wed) by paulj (subscriber, #341) [Link] (6 responses)

Ah yes, the damn POSIX epoch specifies time since in Epoch in UTC. I thought it was just "seconds since epoch". :(

Anyway, the question remains: exactly who needs to have the leap-second occur as an inserted second, rather than a spaced out smear?

People who need precise control/responses: They definitely don't want it, they need accurate relative time.

People who need 1±0.1 second accuracy to the global reference of UTC: well, that must be because they need to compare time across systems. In which case, they need some *other* system to synchronise time across those systems, such as NTP. If those systems are within one organisation, they can use NTP to do the slew in a relatively co-ordinated fashion.

So whose left? It seems to me that it must be organisations who wish to compare time to ±0.1s accuracy across systems distributed over multiple organisations, who do not normally work closely enough together that they can arrange to synchronise to anything other than UTC.

So how many such organisations exist with those kinds of requirements? What is the application? Is it even realistic to expect ±0.1s accuracy in timestamps at such scales?

Why hold the reliability of our software hostage to requirements that few likely need or care about? Would it be possible to punt to userspace, and have NTP handle the method, through an interface that allows the kernel to be agnostic about it? Wouldn't that be much much better for pretty much everyone? (Don't you need to run NTP in the first place in order to get the leap-second?).

Leaping seconds and looping servers

Posted Jul 4, 2012 14:01 UTC (Wed) by faramir (subscriber, #2327) [Link] (3 responses)

I have this feeling that you have just described "the stock market". If true, that would pretty much explain why everyone ends up caring.

Leaping seconds and looping servers

Posted Jul 4, 2012 14:22 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Trading requires imposing an absolute ordering - not an absolute time. You could specify order with UTC time-stamps I guess, but still you'd want a central arbiter to provide those time-stamps. Otherwise you'd need an honour system to settle trades - which surely would be open to abuse?

Leaping seconds and looping servers

Posted Jul 4, 2012 17:56 UTC (Wed) by jwakely (subscriber, #60262) [Link]

You only need an ordering at the matching engine. But most participants in the markets are not running matching engines. For measuring the age of quotes and your network latency and your software latency and the latency of messages from the exchange and the latency of messages from other sources and numerous other measurements you want accurate (definitely sub-0.1s!) timestamps, that agree across multiple organisations.

Leaping seconds and looping servers

Posted Jul 7, 2012 1:13 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

Some people were very happy that June 30 was not a trading day!

Leaping seconds and looping servers

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

Ah yes, the damn POSIX epoch specifies time since in Epoch in UTC. I thought it was just "seconds since epoch". :(

Well, to be precise, there's no such thing as time since X in UTC. UTC is means of identifying a moment in time that involves year, month, day, etc. It implicitly provides a means of identifying certain intervals too, for example tells you what "February 1992" is. It doesn't deal with lengths of time (periods).

The relationship between the POSIX time representation and UTC is that the POSIX count assumes 60 seconds in every UTC minute, regardless of how long that minute actually lasts.

Leaping seconds and looping servers

Posted Jul 12, 2012 18:59 UTC (Thu) by VITTUIX-MAN (guest, #82895) [Link]

"Anyway, the question remains: exactly who needs to have the leap-second occur as an inserted second, rather than a spaced out smear?"

Any system that has heterogenous hardware and software that nevertheless passes around time stamps, could get upset if different machines used heterogenous sources of time as well, so that this smearing wont happen in unison. That is, different ntp servers some of which smear, others not or they use different smear period and interwall.

Rare - surely, as rare as leap second problems, but have a million systems, and a few gets hitten by this hard.