Leap-second decision delayed by eight years | Hacker News Reader

Leap-second decision delayed by eight years

nature.com

40 pointsskreuzer23 comments

"Once the drift is appreciable, the argument goes, a correction could be added much further down the line, perhaps by adding a leap minute or hour."

Well.. if the leap second is any lesson, that should go smoothly and be really easy to implement.

True, although for the same reasons that "fail fast" is sometimes better than the alternatives, a "leap hour"---being much easier to perceive than a leap second---may be easier to work with. At least then you'll know if someone's off because they didn't leap, vs some sort of clock drift or other error.

Wait - for "fail fast" reasons, we're going to do something important every few thousand years, instead of about once a year?!

If it is an hour then you would just change the time zones ... assuming that we even still have those.

Why are these options mutually exclusive? Is there some technical limitation here preventing us from having one monotonic clock and a separate orbital clock?

Both of those already exist, and in fact the GPS system uses the orbital clock, for obvious reasons. People are arguing about the default... always fruitless.

The UNIX 'zoneinfo' format is flexible enough to incorporate second offsets, so this can be done on many systems today (Linux, *BSD (the latter including, I assume, OS X)).

The system clock would be kept in TAI (or maybe GPS, which is a fixed number of seconds different than TAI?) and the local time is calculated by applying a timezone offset in seconds.

http://www.ucolick.org/~sla/leapsecs/right+gps.html

Given that the leap-second problem exists, this is the right technical way to deal with it. Unfortunately I've never seen anyone doing this, but they should.

(Of course it'd be ideal if humans were willing to abandon their silly timezones, and just plan schedules in absolute time that made sense for their geography. Alas, not sure we're ready as a species for this level of change.)

No, but there's always going to be a standard time, and that one slowly becomes meaningless if we let it drift out of sync with the Earth.

http://physics.nist.gov/cuu/Units/second.html

Seconds have been independent of solar time for quite a while.

From https://github.com/urbit/urbit/blob/master/include/vere/vere...

    /*  Urbit time: 128 bits, leap-free.
    **
    **  High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012)
    **  Low 64 bits: 1/2^64 of a second.
    **
    **  Seconds per Gregorian 400-block: 12.622.780.800
    **  400-blocks from 0 to 0AD: 730.692.561
    **  Years from 0 to 0AD: 292.277.024.400
    **  Seconds from 0 to 0AD: 9.223.372.029.693.628.800
    **  Seconds between 0A and Unix epoch: 62.167.219.200
    **  Seconds before Unix epoch: 9.223.372.091.860.848.000
    **  The same, in C hex notation: 0x8000000cce9e0d80ULL
    **
    **  New leap seconds after July 2012 (leap second 25) are ignored.  The
    **  platform OS will not ignore them, of course, so they must be detected
    **  and counteracted.  Perhaps this phenomenon will soon find an endpoint.
    */

There's a standard for what this is trying to do: TAI, or TAI with an offset of 19 seconds, like GPS.

Rolling your own is never a good idea.

Yes, this equates to TAI minus 35 seconds. GPS did exactly the same thing (instantiated at a TAI offset equal to UTC), perhaps in a vain hope that the astronomers would give up their death-grip on time. Not sure the difference between 35 and 19 amounts to "rolling your own."

(At least future decisions are out of the hands of the astronomers and into the hands of the timekeepers, so maybe these responsible authorities will just refuse to declare further leap seconds regardless of heavenly tantrums.)

The comment just describes a trivial notation for representing 128-bit TAI as an unsigned integer. The closest comparable "standard" that I know of is DJB's TAI64 [1]. (Everything released by DJB should be regarded as a standard.) But TAI64 is (a) defined as a bytestream, not a uint128_t; and (b) has a hopelessly complicated fractional subsecond system.

[1] http://cr.yp.to/proto/tai64.txt.

This scheme is different due to the way it handles times between the start of leap seconds and 2012.

And, as an astronomer turned technologist, I think your comments are completely inappropriate for civilized discussion. If you want verbal mud-wrestling, take it elsewhere.

There is no "0AD", and if you don't have leap seconds then the number of seconds per repeat of the Gregorian calendar is not fixed—just have a look at the graph at http://www.ucolick.org/~sla/leapsecs/deltat.html

There may be at least 8 different answers to "how many seconds have elapsed since 1972-01-01 until now" depending on legal jurisdictions: http://www.ucolick.org/~sla/leapsecs/epochtime.html

[ed: added second link]

TLDR: if you define a bunch of complexity into your definition of time, you'll have a very complex model of time.

Eg, if you define the Gregorian calendar as a function of the position of the planets, rather than a function from atomic-clock seconds to a string, then the Gregorian calendar is not fixed. I suppose Pope Gregory designed it as a function of astronomy, so who are we to roll our own?

UTC does not bear an appreciably worse relationship to my local solar time than GMT. For that matter, at the granularity of seconds my time zone is pretty far off from solar time and 20 miles down the road is about as bad but an hour earlier.

Clocks are useful for coordinating human events. The idea that they have some deep relationship to the cosmos is a conceit as useless as the geocentric solar system model.

Except historically some humans have found it useful to coordinate certain events to, say, recur at the same time of winter every year so suddenly a deeper relationship to the cosmos becomes necessary.

By "deep of winter" can I assume you were referring to July?

No, winter was an arbitrary example. Humans need to track yearly events during all seasons.

Complexity in this case can only be added, not subtracted. However I think there is huge demand for the simplest yet most accurate shared monotonic counter, and you want it to act as unsurprising as possible, and to be as widely adopted as possible. UTC has pretty wide adoption as far as things go, so they have that going for them.

If we were to require but not have one leap second a year into perpetuity, it would take 1000 years to drift 1/4h off from true time.

That's 1000 years of more regular, workable time. And I'd hope in 1000 years people would have adjusted to the small offset.

Plus, one hour-big adjustment every 4000 years is certainly easier than 4000 second-long adjustments every year, if they really haven't gotten used to it by then. Note that 4000 years ago we hadn't an alphabet - no doubt we'll be thought of on equal footings.

as long as it is still monotonically increasing i don't really mind the labeling... =D

Reply on news.ycombinator.com