

The One-second War (What Time Will You Die?)   - yarapavan
http://queue.acm.org/detail.cfm?id=1967009

======
ars
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.

~~~
dspeyer
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.

------
ambiguity
Java fail.

Here is a link to the PDF version:
[http://portal.acm.org/ft_gateway.cfm?id=1967009&type=pdf...](http://portal.acm.org/ft_gateway.cfm?id=1967009&type=pdf&CFID=16929106&CFTOKEN=62823757)

------
edoloughlin
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.

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

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

------
daniel02216
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.

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

~~~
daniel02216
...yeah. :)

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

------
zheng
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...

~~~
Tuna-Fish
It already did.

sizeof(time_t) == 8 on my machine.

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

------
udoprog
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.

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

~~~
gjm11
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.

~~~
qntm
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.

~~~
gambler
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.

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

