Leaping seconds and looping servers
Posted Jul 9, 2012 15:57 UTC (Mon) by giraffedata
In reply to: Leaping seconds and looping servers
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.
to post comments)