Leaping seconds and looping servers

Posted Jul 9, 2012 15:57 UTC (Mon) by giraffedata (guest, #1954)
In reply to: Leaping seconds and looping servers by dgm
Parent article: Leaping seconds and looping servers

Users of computers want traditional UTC-style year-month-day etc.
users really don't care about UTC, 99% of the time they want the time their watch says it is.

Every watch in the world displays traditional UTC-style year-month-day etc. My point is that POSIX time makes it more practical for a computer to display that than a straight seconds-since epoch time format would. Or are you referring to the watch being inaccurate?

And you still need complex time handling code because there are such niceties as timezones, local calendars, different week conventions, and even time dilation!

Except for the time dilation, which history proves you don't need in your time handling code, those are all simpler to handle than leap seconds. Asking the computer to understand leap seconds is asking for a whole other level of computation. The most significant part of that is knowing when the leap seconds are.

What exactly is solved forcing the duration of the day?

At the risk of being repetitive, it allows for practical calculation of UTC-style, wristwatch-style datetimes. Also for calculating differences in the larger units such as hours and days (when a computer user says "3 days after 10:00 Wednesday," he normally means 10:00 Thursday, not 86400*3 seconds after 10:00 Wednesday).

It also causes or fails to solve some other problems. The only question is which problems are greater?

By the way, if unambiguous datetimes were seen as a problem worth solving in the days that POSIX was invented, I think the proper solution would have been to go with the same "seconds since epoch not counting leap seconds" and then have a separate bit saying "leap second" that the folks who need to distinguish between 23:59:59 and 23:59:60 could use. Practically computable datetimes are that important.

Leaping seconds and looping servers

Posted Jul 9, 2012 18:44 UTC (Mon) by dark (guest, #8483) [Link] (1 responses)

Ah, but consider the user who says "3 days after Friday 10:00". Presumably that user wants "Monday 10:00", and not "Monday 9:00, 10:00 or 11:00 depending on whether there is a DST transition this weekend". So yeah, you can't use 86400*n anyway. Unless you want to mishandle DST, which is the option chosen by the vast majority of applications :)

Leaping seconds and looping servers

Posted Jul 9, 2012 23:16 UTC (Mon) by dgm (subscriber, #49227) [Link]

Indeed. 1 day = 86400 seconds is a computation that was broken from the start. It wasn't working back in the day POSIX was defined, and of course, things could only go downhill from there.

As a bunch of others have pointed out, leap seconds are very similar in essence to timezones -or any other oddity of civil time- in that they are _arbitrary_. They really belong in the code that has no choice but to handle them: the system libraries (glibc for modern Linux distros).