|
HP OpenVMS Systemsask the wizard |
|
The Question is:
The C langage localtime returns a time that is one hour off.
$ cc/noopt/deb t
$ lin t/deb
$ run t
OpenVMS Alpha Debug64 Version V7.2-019
~stepped through code
DBG> type 1940:1946
module T
1940: main()
1941: {
1942: tm_t *z; time_t t;
1943: t = time(0);
1944: z=localtime(&t);
1945: return;
1946: }
DBG> exam @z
*T\main\z
tm_sec: 58
tm_min: 16
tm_hour: 14 <== Note that time is one hour off
tm_mday: 7
tm_mon: 11
tm_year: 99
tm_wday: 2
tm_yday: 340
tm_isdst: 0
tm_gmtoff: -28800
tm_zone: 2315912
DBG> Exit
$ show time
7-DEC-1999 15:17:51
$ cc/version
DEC C V6.0-001 on OpenVMS Alpha V7.2
$ sh log/sys *time*
(LNM$SYSTEM_TABLE)
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.US]PACIFIC."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "-25200"
"SYS$TIMEZONE_NAME" = "PDT"
"SYS$TIMEZONE_RULE" = "PST8PDT7,M4.1.0/2,M10.5.0/2"
"TCPIP$BIND_TIMEOUT" = "...."
"TCPIP$CFS_ATTR_CACHE_TIMEOUT" = "5"
The Answer is : The setting of the tm_isdst field clearly indicates that the system had determined that daylight savings time (DST) is not in effect, and thus that the current time is Standard Time. Now, as to why this has occured... The localtime() function was given the correct UTC. The localtime() function itself knows exactly nothing about the OpenVMS UTC system services, the timezone differential factor (TDF), and other OpenVMS system-specific creatures. What it does know about are the rules in the timezone file. According to the timezone rules, the month of December is Standard Time. While mapping a given UTC time to the local time, the localtime() function applied the offset for Standard Time and returned the correct Standard Time corresponding to the correct UTC time returned by the time() function. Of course, this correct Standard Time was one hour off from the phony DST time on the system.
|