Peter N Lewis wrote:

...

: - 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.

Yes, the tm struct has this field. It looks to me like you should call localtime to get it as otherwise it might not initialize the timezone stuff.

Yes, localtime is called, anyway.

...

The descriptions also made me aware of the sign issue (which I hadn't considered before). Which sign is the "correct" one?

Correct timezones are positive east. We are at +8 hours, the USA is roughly -8 hours.

This is the first I've ever heard of anyone doing positive timezones going west.

http://www30.cds.ne.jp/~yukinaka/eureka/library/articles/etc/timezone.html http://www.zill.net/pgdocs/timezones.html etc

Thanks for the references. I'll change it (even if it means another incompatible change).

Gale Paeper wrote:

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.

I think you see a problem where none exists. We do have such a structure (returned by localtime), so we can just use this field.

Frank