Michael G Schwern wrote:
John E. Malmberg wrote:
Default:
Thanks, that looks all correct. If you could try the latest version of the
code that would be great. It makes it more accurate for systems which have
silly failure points, like Y10K.
http://code.google.com/p/y2038/source/browse/trunk/bin/check_max.c
EAGLE> cc check_max
EAGLE> link check_max
EAGLE> run check_max
gmtime max 4294967295
localtime max 4294967295
gmtime min 0
localtime min 0
EAGLE> cc check_max/define=__SIGNED_INT_TIME_T
EAGLE> link check_max
EAGLE> run check_max
gmtime max 2147483647
localtime max 2147483647
gmtime min 3221225472
localtime min 3221225472
VMS keeps time internally as a 64 bit signed integer all platforms,
usually in local time. The base time is November 17, 1958
What do localtime() and gmtime() think time_t = 0 is?
#include <time.h>
#include <stdio.h>
int main(void)
{
struct tm *date;
time_t time = 0;
date = gmtime(&time);
printf("# %04d.%02d.%02d %02d:%02d:%02d\n",
date->tm_year + 1900,
date->tm_mon + 1,
date->tm_mday,
date->tm_hour,
date->tm_min,
date->tm_sec
);
return 0;
}
EAGLE> cc check_time_0.c
EAGLE> link check_time_0
EAGLE> run check_time_0
# 1970.01.01 00:00:00
Substituting localtime for gmtime gives this for my timezone.
# 1969.12.31 18:00:00
For VMS, most of the routines that generate a time_t value are already
handled by wrapper routines. It is possible that at some time in the
future, even if the C library does not support it, Perl on VMS could
support a 64 bit time_t type.
-John
[EMAIL PROTECTED]
Personal Opinion Only
