[tz] Timezone for Moscow is -10800 after installing tzdata-2014g

[Paul Eggert]

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 
called it.

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