[H-GEN] time in C/C++

Martin Pool martinp at mincom.com
Wed Dec 29 01:08:53 EST 1999


[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics.  Please observe the list's charter.          ]

Frank Brand wrote:
> >        POSIX.1  defines  seconds since the Epoch as a value to be
> >        interpreted as the number of seconds between  a  specified
> >        time  and the Epoch, according to a formula for conversion
> >        from UTC equivalent to conversion on the naïve basis  that
> >        leap  seconds are ignored and all years divisible by 4 are
> >        leap years.
> >
> > Note: *all* years divisible by 4 are leap years. No 100 or 400 rule.
> >
> > Whether this is true or not is another matter...
> 
> Yes, these are the two aspects to which I was referring, the second regarding
> leap years is more of a potential problem than the first to me. The first might
> result in a few seconds error but the second might, in some circumstances,
> result in a more significant error although, in practical terms, it would be a
> long while before it would be a problem. Under this arrangement 2000 would be
> treated as a leap year and the next error might not occur until the year 2100
> which would be treated as a leap year when, in fact it is not.

Obviously this area has to be re-examined anyhow to handle y2038, so
whether it works in 2100 is moot.

I'm sure you can find good calendar libraries in your favourite
language.  It seems silly to reimplement it.  For financial applications
the Mac-style "uint32 days since 1904" might be good, and it neatly
avoids leap seconds altogether.

It's not too much of a stretch to imagine that before 2100 there will be
more than a few computers and people not on planet Earth.  That's
certainly going to complicate timezones and calendars.  It's confusing
enough talking to people in the states who are still in Tuesday
afternoon, but imagine talking to people on Mars with a 25-hr day.

Some C libraries try to split time_t into parts using an interative
algorithm, so on 64-bit platforms would hang if passed (time_t)-1 ! :-)

-- 
 /\\\  Mincom | Martin Pool          | martinp at mincom.com
// \\\        | Software Engineer    | Phone: +61 7 3303-3333
\\ ///        | Mincom Limited       | Teneriffe, Brisbane
 \///         | And now a word from our sponsor...

This transmission is for the intended addressee only and is
confidential information. If you have received this
transmission in error, please delete it and notify the
sender. The contents of this E-mail are the opinion of the
writer only and are not endorsed by Mincom Limited unless
expressly stated otherwise.

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.



More information about the General mailing list