Gale Paeper wrote:
Frank Heckenbach wrote:
What does the following C program give?
#include <stdio.h> #include <sys/time.h>
#if 0 /* Set if variable not defined */ extern long int timezone; #endif
int main () { time_t s = (time_t) time (0); localtime (&s); printf ("%li\n", (long int) timezone); return 0; }
Do you find any mentioning of `timezone' in the system headers?
On Mac OS X 10.2.4, `timezone' is defined in <sys/time.h> as:
struct timezone { int tz_minuteswest; /* minutes west of Greenwich */ int tz_dsttime; /* type of dst correction */ };
That's something different (`struct timezone' and `timezone' are two completely unrelated "names" in C ...).
There is also a definition in <time.h> if _ANSI_SOURCE and _POSIX_SOURCE aren't defined:
char *timezone __P((int, int));
That's it. So it's a function and treating it as an integer variable obviously produces nonsense.
There is also a note in man GETTIMEOFDAY(2) which states timezone (I think as a variable) is no longer used. In addition, I see there are gpc and gcc configuration tests for the availability of timezone.
(As a variable.)
In the glibc manual I found this:
: - Variable: long int timezone : This contains the difference between UTC and the latest local : standard time, in seconds west of UTC. For example, in the U.S. : Eastern time zone, the value is `5*60*60'. Unlike the `tm_gmtoff' : member of the broken-down time structure, this value is not : adjusted for daylight saving, and its sign is reversed. In GNU : programs it is better to use `tm_gmtoff', since it contains the : correct offset even when it is not the latest one.
: - Data Type: struct tm : : [...] : : `long int tm_gmtoff' : This field describes the time zone that was used to compute : this broken-down time value, including any adjustment for : daylight saving; it is the number of seconds that you must : add to UTC to get local time. You can also think of this as : the number of seconds east of UTC. For example, for U.S. : Eastern Standard Time, the value is `-5*60*60'. The : `tm_gmtoff' field is derived from BSD and is a GNU library : extension; it is not visible in a strict ISO C environment.
I think I could check for this field and use it where available. If this is present on Mac OS X (I hope so, since the field seems to come from BSD), this might solve the problem.
The descriptions also made me aware of the sign issue (which I hadn't considered before). Which sign is the "correct" one? (Independently of the C semantics, since we can easily flip it if necessary.) Mail headers, e.g., use the latter one (negative in the west, positive in the east), so I'd tend to it (which would change GPC's current behaviour, but I don't think it's too firmly established yet). But are there any relevant standards?
Frank