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

[Guy Harris]

On Oct 4, 2014, at 2:58 AM, Alan Barrett <apb at cequrux.com> wrote:

> On Fri, 03 Oct 2014, Paul Eggert wrote:
>> When tzset is called, it does not know what time stamps you are interested in. It guesses, and its guess is based on time stamps that are farthest in the future.
> 
> 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.
> 
> 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.  This would not detract from tzset()'s other task of setting internal variables to refer to the rules for the local time zone, for use by localtime(), mktime(), and other time zone functions.
> 
> Are these global variables documented as deprecated?

Sadly, no.

They're not in the C standard at all.  However, they *are* in the current version of POSIX, which is also the current version of the Single UNIX Specification; tzset() sets tzname[] and, if the system conforms to the X/Open System Interfaces option, timezone and daylight, and "local timezone information is used as though localtime() calls tzset()."

localtime_r() need not set tzname[] and, if it doesn't, it also need not set timezone nor daylight.

The Single UNIX Specification allows the tz database to be used, although it doesn't require it to be used.  The TZ environment variable is set either to a standard POSIX-style tz string or to a colon followed by an implementation-dependent string; the latter was put in there for non-standard TZ settings such as tz database tzids.

The SUS only specifies the behavior for standard POSIX-style tz string settings of TZ.  Those settings specify only one local offset from UTC (which is for standard time), one pair of time zone abbreviations (one for standard time and one for daylight savings/summer time), and one indication of whether daylight savings time is used or not (so that a setting such as EST5EDT would set daylight to a non-zero value and EST5 would set it to 0), so tzname[], timezone, and daylight can be set from TZ and never change.  If TZ is set to, for example, refer to a tz database tzid, the SUS doesn't indicate how tzname[], timezone, or daylight are set.