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 */ };

There is also a definition in <time.h> if _ANSI_SOURCE and _POSIX_SOURCE aren't defined:

char *timezone __P((int, int));

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.

Perhaps there is some sort of config problem with the Mac OS X GPC build which is the root source of the problem.

FYI, the complete output of man gettimeofday is:

GETTIMEOFDAY(2) System Calls Manual GETTIMEOFDAY(2)

NAME gettimeofday, settimeofday - get/set date and time

SYNOPSIS #include <sys/time.h>

int gettimeofday(struct timeval *tp, struct timezone *tzp);

int settimeofday(const struct timeval *tp, const struct timezone *tzp);

DESCRIPTION Note: timezone is no longer used; this information is kept outside the kernel.

The system's notion of the current Greenwich time and the current time zone is obtained with the gettimeofday() call, and set with the settimeofday() call. The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970. The resolution of the system clock is hardware dependent, and the time may be updated continuously or in ``ticks.'' If tp or tzp is NULL, the associated time information will not be returned or set.

The structures pointed to by tp and tzp are defined in <sys/time.h> as:

struct timeval { long tv_sec; /* seconds since Jan. 1, 1970 */ long tv_usec; /* and microseconds */ }; struct timezone { int tz_minuteswest; /* of Greenwich */ int tz_dsttime; /* type of dst correction to apply */ };

The timezone structure indicates the local time zone (measured in minutes of time westward from Greenwich), and a flag that, if nonzero, indicates that Daylight Saving time applies locally during the appropriate part of the year.

Only the super-user may set the time of day or time zone. If the system securelevel is greater than 1 (see init(8) ), the time may only be advanced. This limitation is imposed to prevent a malicious super-user from setting arbitrary time stamps on files. The system time can still be adjusted backwards using the adjtime(2) system call even when the sys- tem is secure.

RETURN A 0 return value indicates that the call succeeded. A -1 return value indicates an error occurred, and in this case an error code is stored into the global variable errno.

ERRORS The following error codes may be set in errno:

[EFAULT] An argument address referenced invalid memory.

[EPERM] A user other than the super-user attempted to set the time.

SEE ALSO date(1), adjtime(2), ctime(3), timed(8)

HISTORY The gettimeofday() function call appeared in 4.2BSD.

4th Berkeley Distribution May 26, 1995 4th Berkeley Distribution

Note: If one looks at the raw man file, it looks like it comes from an OpenBSD distribution.

Gale Paeper gpaeper@empirenet.com

Frank Heckenbach wrote:

Gale Paeper wrote:

[snip]

...

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.

I don't think any variable solution is going to work for Mac OS X's <time.h> or <sys/time.h>.since there is no guarenteed storage allocated variables declared in the headers. (There is one iffy, extern char *tzname[], but it is dependent upon _ANSI_SOURCE not being defined.) Everything guarenteed to be always present in those two headers are just preprocessor defines of constants and macros, type declarations, and function declarations.

There is a `tm_gmtoff' field in <time.h>; however, it is just a struct field in a type declaration:

struct tm { int tm_sec; /* seconds after the minute [0-60] */ int tm_min; /* minutes after the hour [0-59] */ int tm_hour; /* hours since midnight [0-23] */ int tm_mday; /* day of the month [1-31] */ int tm_mon; /* months since January [0-11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday [0-6] */ int tm_yday; /* days since January 1 [0-365] */ int tm_isdst; /* Daylight Savings Time flag */ long tm_gmtoff; /* offset from CUT in seconds */ char *tm_zone; /* timezone abbreviation */ };

So, in brief, on Mac OS X, the only thing available in <time.h> or <sys/time.h> to get a valid value for TimeStamp's timezone field is one of the available, appropriate function calls. Since I don't have the breadth of systems experience necessary, I don't know what to suggest for a GPC solution. If it would help, Frank, I could send you copies of the two Mac OS X hearder files in private e-mail.

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?

I really don't know. We're in areas I've never had to deal with before.

Gale Paeper gpaeper@empirenet.com