Re: End of the Epoch

Keith Thompson wrote:
Joe Wright <joewwright@xxxxxxxxxxx> writes:
Keith Thompson wrote:
Keith Thompson <kst-u@xxxxxxx> writes:
Joe Wright <joewwright@xxxxxxxxxxx> writes:
I've always found that most C implementations come up with the same
results in most situations. Imagine my surprise when I found that
DJGPP and Microsoft don't agree on the End of the Epoch. Consider:

#include <stdio.h>
#include <time.h>
int main(void) {
time_t tim = 0x7fffffff;
printf("%d %s", (int)tim, ctime(&tim));
return 0;
}

2147483647 Tue Jan 19 03:14:07 2038 with DJGPP (gcc)
2147483647 Mon Jan 18 22:14:07 2038 with Microsoft

Five hours different. I'm working on which, if either, I think is
correct. What do you get?
Try printing the current time. I'll bet one is using UTC and the
other is using local time. (Are you in the US Central time zone?)
Correction: make that Eastern. If I'm right, your current offset from
UTC (or GMT) is 4 hours, but in January it's 5 hours.

Of course, the C standard says very little about time_t; the only
requirement is that it's an arithmetic type capable of representing
times.
Good catch.

1241215084 Fri May 1 21:58:04 2009 DJ
1241215084 Fri May 01 17:58:04 2009 MS

4 hours in May. MS using GMT and DJ EDT to set time_t. Testing with
tim=0, MS gave me 'Wed Dec 31 19:00:00 1969'.

You generated that output at 9:58pm in your local time, yes?

Yes it was.

They're both setting the time_t value the same way; note that they
both return the same value for time(NULL).

1241263555 Sat May 02 07:25:55 2009 MS
1241249162 Sat May 2 07:26:02 2009 DJ

For time(NULL) at any given moment here in Virginia, the value from MS is 14400 greater than that from DJ.

ctime(t) is equivalent to asctime(localtime(t)). The difference is in
what local timezone they're using for localtime(); DJ is using the
actual local timezone (EDT), and MS is using UTC.

When installing Windows you are asked for your Time Zone and therefore relation to UTC. DJGPP was implemented for MSDOS where no such information is available.

And using "May 01" rather than "May 1" is non-conforming; the English
description of asctime() in C99 7.23.3.1 allows for either, but the
algorithm does not. (And let's not get into the old debate about
whether the algorithm is buggy; it works fine in this particular
case.)

It's astonishing that Microsoft might be non-conforming in any way. :-)

--
Joe Wright
"Memory is the second thing to go. I forget what the first is."
.

Relevant Pages

  • Re: End of the Epoch
    ... UTC is 4 hours, but in January it's 5 hours. ... You generated that output at 9:58pm in your local time, ... actual local timezone, ... whether the algorithm is buggy; it works fine in this particular ...
    (comp.lang.c)
  • Re: NTPD not keeping time
    ... CMOS/BIOS clock ... UTC, not your local timezone. ... Want to start your own business? ...
    (freebsd-questions)
  • Re: Using syslog(3) after chroot-ing
    ... On Jun 29, 2004, at 6:22 PM, Mikhail Teterin wrote: ... > Is there a similar trick to make it use the local timezone instead of ... > UTC? ...
    (freebsd-questions)
  • Re: Time change questions !
    ... NTP exchanges time information in UTC, but knows how to convert to ... be UTC) all of the implementations of NTP on VMS have to convert between UTC ... and the local timezone when correcting the VMS system's clock. ...
    (comp.os.vms)
  • Re: NTPD not keeping time
    ... CMOS/BIOS clock ... UTC, not your local timezone. ...
    (freebsd-questions)