utisoft at gmail.com
Wed May 29 11:04:54 UTC 2013
On 29 May 2013 07:13, "Matthew Seaman" <matthew at freebsd.org> wrote:
> On 29/05/2013 05:59, Michael Sierchio wrote:
> > On Tue, May 28, 2013 at 4:45 PM, Joshua Isom <jrisom at gmail.com> wrote:
> >> You think it's trivial until you read this:
> >> http://infiniteundo.com/post/**25326999628/falsehoods-**
> >> programmers-believe-about-time<
> > Some days have 86400 seconds, some have 86401. There is a provision for
> > two leap seconds to be applied at once, but that hasn't ever happened.
> > Still, a truly correct clock, set to UTC, might someday read
> > 23:59:59
> > 23:59:60
> > 23:59:61
> > 00:00:00
> > How many seconds did that hour have?
> Right. The fact that on very rare occasions a minute may not have 60
> seconds in it plus many other corner cases in calculating the current
> wall-clock time is an amusing irrelevance.
> First of all, sleep deals in local elapsed time, which is a well defined
> property even if the displayed wall-clock time would be all over the
> place due to DST changes or relativistic effects or whatever.
> In this case, I'd be pretty surprised if GNU sleep's algorithm was
> anything more complicated than to convert the stated time into seconds
> and then sleep that number of seconds. And to do that conversion, it
> wwould just define one minute as 60 seconds, one hour as 60 minutes, one
> day as 24 hours, one week as 7 days, perhaps one month as 30 days, one
> year as 365 days[*]. Sure, it's simplistic and unsophisticated, but as
> an engineering solution it's good enough for the vast majority of
OK, but is this really something the OS should handle? I'm sure sleep
`expr 3600 \* 2` will suffice and is perfectly readable, including being
Why should we keep putting these weird "extensions" in? At some point it
just becomes fiddling, and yet another source of error when porting....
More information about the freebsd-questions