[tz] Timezone for Moscow is -10800 after installing tzdata-2014g
eggert at cs.ucla.edu
Sat Oct 4 16:53:13 UTC 2014
Alan Barrett wrote:
> So, after calling tzset(), the global timezone variable will contain the UTC
> offset that would be in effect at some time in the very distant future. Other
> global variables similarly refer to what would be in effect in the distant future.
The 'daylight' global variable is OK, as its value is the same no matter what
timestamp you're interested in. But yes, the values of 'timezone' and 'tzname'
depend on the timestamp. In the POSIX-only world this is not a problem, since
its time zones are so simple that 'timezone' and 'tzname' are invariants for
each zone. But that is not true of tz database time zones.
> Perhaps it would be more useful for tzset() to set global variables based on
> what would be appropriate for the instant when tzset() is called.
It's probably not worth the bother. For one thing, it'd be another system call;
and Guy mentioned it'd cause tzset to behave differently depending on when you
If I get up the time and energy I'll try to get them removed from POSIX. There
is no need for any of these variables. strftime's %Z obsoletes tzname for
practical uses. And 'daylight' and 'timezone' are useless variables; they don't
suffice even to support the POSIX model, since they assume that DST is one hour
away from standard time, which means one cannot reliably use them to compute the
UTC offset when tm_isdst is positive. And all these variables are inherently
non-thread-safe, so even tzname is useless in multithreaded programs that call
tzset (which is itself required to be thread-safe).
More information about the tz