| |||||||||||||
Leaping seconds and looping serversLeaping seconds and looping serversPosted Jul 6, 2012 17:14 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Leaping seconds and looping servers by dgm Parent article: Leaping seconds and looping servers
Forcing the 1 day=86400 seconds stuff was one of the worst ideas ever ... Had they just kept as a simple count of seconds, that would have been useful and simple. And less error prone. You might be able to argue that in 2012 it would be better for POSIX to specify a simple count of seconds, but if you look at how the world was when that time format was invented, there just can't be any question that not including leap seconds in the count was the right thing to do. Users of computers want traditional UTC-style year-month-day etc. datetimes. To convert from a simple count of seconds to that requires not only significantly more code to be written but some way to know when the leap seconds were. A file, a manual maintenance procedure, or a global computer network, all of which were simply not practical enough to meet the timekeeping requirements of the users. Most of the present discussion isn't about whether the POSIX standard should be a simple count of seconds, but whether the kernel's time base should be. POSIX doesn't say how anyone has to keep time; it just says how it gets communicated. Either way, some users are going to be adjusting for leap seconds; some adding them, others removing them.
(Log in to post comments)
Leaping seconds and looping servers Posted Jul 9, 2012 11:33 UTC (Mon) by dgm (subscriber, #49227) [Link]
> there just can't be any question that not including leap seconds in the count was the right thing to do.
It was a mistake, and no amount of historic excuses can make it a right decision. I never was the right thing to do, neither is it now.
> Users of computers want traditional UTC-style year-month-day etc.
Users don't talk to the kernel, nor with the system libraries. They talk to applications. And by the way, users really don't care about UTC, 99% of the time they want the time their watch says it is. Until that's not enough, and then what they want is an _unambiguous_ moment in time. Anything between those extremes is completely useless.
> To convert from a simple count of seconds to that requires not only significantly more code to be written but some way to know when the leap seconds were.
What exactly solved forcing the duration of the day? Nothing, everything is exactly as complex as it was, but now you have that "fictional" day which is different from what users need. And you still need complex time handling code because there are such niceties as timezones, local calendars, different week conventions, and even time dilation!
> Most of the present discussion isn't about whether the POSIX standard should be a simple count of seconds, but whether the kernel's time base should be.
The mere fact that there's a discussion is a sign that people are not sufficiently aware of past mistakes. We should be raising awareness of this, with the goal of avoiding repeating them. The Kernel should just count time in the most unambiguous way it can, and let applications handle the presentation.
> POSIX doesn't say how anyone has to keep time; it just says how it gets communicated.
An application cannot give the user an unambiguous moment in time if all it can get from POSIX is an ambiguous representation. That is the crux of the matter.
Leaping seconds and looping servers Posted Jul 9, 2012 15:57 UTC (Mon) by giraffedata (subscriber, #1954) [Link] 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 (subscriber, #8483) [Link] 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).
|
|||||||||||||