The One-second War (What Time Will You Die?) | Hacker News Reader

The One-second War (What Time Will You Die?)

queue.acm.org

66 pointsyarapavan18 comments

I think unixtime should run with no discontinuities, and leap seconds should be handled just like timzezones are: Have a table with leap seconds, and consult it as necessary. Don't change the internal clock - only change the display.

i.e. instead of storing UTC in the clock, store TAI, and calculate UTC (or local time) from it.

That would also work well with his proposal of scheduling leap seconds 20 years in the future, and without messing with the length of a day in calculations, or having discontinuities.

The part about scheduling 20 years in advance is the one bit that didn't seem well thought out. We don't know this stuff in advance. We can't even predict earthquakes. Anything that changes the earth's effective radius changes the rotation.

Keeping and updating a table might be workable anyway. It can't be much worse than pushing all the new daylight savings rules.

Java fail.

Here is a link to the PDF version: http://portal.acm.org/ft_gateway.cfm?id=1967009&type=pdf...

The “programmers should fix their past mistakes for free” argument is amusing when you consider that the leap second concept is nothing more than an hack.

Personally, I favour manually adjusting the Earth's orbital and rotational characteristics to match atomic time.

Or using a system of time not correlated to the rotation of the planet. (It is convenient though :( )

It's bad enough that the ACM charges $25 for papers that can be legally found by Googling the name of the paper, but they also can't keep their website alive during a Hacker Newsing at 3AM.

Is there a cached copy somewhere else? Google doesn't have one.

I agree, but it's not 3am across the entire world, it's 9:47am here in the UK, for example.

...yeah. :)

Speaking of the UK, I'm really liking the Hitchhiker's Guide references sprinkled in the article. (reading via the PDF link above)

Very informative article. I've only ever run up against this issue when dealing with age, funny enough. It does seem like a hard problem, but I think I fall with him on the "start doing it right" side. Time stuff has to change by 2038 anyways...

It already did.

sizeof(time_t) == 8 on my machine.

I doubt there will be that many 32bit machines in operation in 2038.

Not by that much. We'll just be using 64 bit.

Date and time representation has always provoked an incredibly uncomfortable itch in me. But I've accepted the fact that represented time will never be exact.

However, by just using relative system times and language specific time/date procedures, there is a good chance of future proofing, no matter the outcome of this.

What is this "interval time" he refers to, and how does it differ from wallclock time?

Interval time is what you use for measuring time intervals. It flows at a rate of 1 second per 9,192,631,770 periods of a particular kind of microwave radiation. It is unaffected by politics, astronomy, etc.

Wall-clock time is what you use when you want to know whether it's 12.34am or 12.35am. It usually increments at the same rate as interval time, but sometimes there are leap seconds, daylight saving time, timezone changes, etc.

Using wall-clock time when what you really want is interval time may result (e.g.) in what was meant to be a 1ms wait turning into a 1hour+1ms wait. That would be bad.

The interesting thing there is that these problems of wall-clock time have largely been solved at every level other than seconds.

Years vary in length - 365 or 366 days. It's 29th February. Add one year. Is it 28th February or 1st March? What if it's 28th February or 1st March now, but next year is a leap year?

Months vary in length - 28, 29, 30 or 31 days. It's 31st March. Add one month. What is the date? 30th April or 1st May? What if it's 30th March? Is your "add one month" function strictly increasing?

We KNOW that days vary in length - 23, 24 or 25 hours. It's 00:59 and the clocks go forward today. Add two minutes. What time is it? 01:01 or 02:01? It's 01:59 and the clocks go back today. Add two minutes. Is it 01:01 or 02:01?

Now we simply have a situation where a minute can also vary in length - 59, 60 or 61 seconds. It's 23:59:58. Add 2 seconds. Is it 00:00:02, 00:00:00 or 23:59:60?

These problems are not difficult. The same approaches can be applied to each one. The only difficulty is awareness. Leap seconds are rarer and less predictable than Daylight Saving, month boundaries or even leap years. But Daylight Saving isn't predictable either - the rules change all the time. Just solve it with tables.

The solutions you describes are designed to keep calendar in sync with Earth rotation around the Sun and around its own axis. However, there is no real need to keep computer timers synchronized with Earth rotation.

The simplest way to keep track of time for computers is to count seconds from a certain agreed-upon point, without leaps, stretches, or arbitrary transition tables - without needless complexity. If I don't care about calendar (Earth rotation) I shouldn't care about any of that stuff either.

In short, no leap seconds would mean simpler, more reliable software.

TAI, then? TAI is UTC but without any leap seconds: http://en.wikipedia.org/wiki/International_Atomic_Time

Reply on news.ycombinator.com