🚀 go-pugleaf

In gnu.utils.help, Paul Eggert <eggert@twinsun.com> writes:
> Russ Allbery <rra@stanford.edu> writes:
>> Dan Kegel <dank@alumni.caltech.edu> writes:

>>> Does anyone have a good autoconf macro for figuring out
>>> how to get at the timezone offset (the extern int) portably?

>> No, but I need to write one for INN as well.

> The most portable way to get the time zone offset is to invoke localtime
> and gmtime on the same time_t value, and then compute the offset
> yourself from the two broken-down times.  This works on any system that
> conforms to either K&R C or to Standard C (either 1989 or 1999).

Right.  This is what INN currently falls back to if struct tm doesn't have
the tm_gmtoff member.

> The 'timezone' variable is less accurate than the portable method, as it
> assumes that the same standard time offset is in effect forever, so it
> mishandles changes to the standard time zone offset (which happened last
> month in Argentina, for example).

Why does it assume that?  I must be missing something.  According to the
Solaris 2.6 man page for the time functions:

     The effects of tzset() are thus to change the values of the external
     variables timezone, altzone, daylight, and tzname.  The ctime(),
     localtime(), mktime(), and strftime() functions will also update
     these external variables as if they had called tzset() at the time
     specified by the time_t or struct tm value that they are converting.

so it seems to me that retrieving the value of timezone if tm_isdst is 0
or altzone if tm_isdst is 1 and daylight is positive, provided it is done
immediately after calling localtime(), would be as accurate as using
tm_gmtoff.  It's unfortunately not MT-Safe, but then localtime() isn't
MT-Safe in general anyway.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>