[shedletsky]

I'm just imagining the subtle bugs that can happen if the developer can't assume a minute is 60 seconds and that each minute is the same length.

This seems like a feature for no one, as the people who really care about leap seconds are probably doing their own timekeeping already since computer clocks aren't exactly accurate to being with.

[batou]

This is not really a problem. Some thoughts:

1. Time is never the same on two different computers.

2. Time is different when you send it and receive it (speed of light).

3. Time isn't necessarily linear (time dilation).

4. Clocks drift, even with NTP.

5. Some systems are isolated enough to accept inaccurate human input and time synchronisation.

Time is an invention for human consumption mainly. Machines are better served with explicit synchronisation (paxos, distributed transactions) or not at all (eventual consistency). Examples in brackets.

Time, if we lose a few seconds here and there, meh, don't sweat it.

[xyzzyz]

Machines are better served with explicit synchronisation (paxos, distributed transactions) or not at all (eventual consistency)

Using atomic clocks to sync distributed systems is actually done in practice.

http://static.googleusercontent.com/media/research.google.co...

[batou]

Utterly insane IMHO. If there's a single error in any temporal data, what happens?

Even relatively reliable frequency/time standards (HP/Agilent come to mind) aren't 100% available.

[bdonlan]

If the leap second was really just expressed to the application as the 61st second of a minute, it wouldn't be so bad. But instead the second of 23:59:59 happens _twice_ (UNIX time steps backwards one second), which tends to confuse applications that assume time increases monotonously.