Re: BSD sleep

From: Chris Rees <utisoft_at_gmail.com>
Date: Wed, 29 May 2013 12:04:47 +0100
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<
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
> purposes.

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
more portable.

Why should we keep putting these weird "extensions" in?  At some point it
just becomes fiddling, and yet another source of error when porting....

Chris
Received on Wed May 29 2013 - 09:04:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC