Red Hat Bugzilla – Bug 1290533
RFC: tzset daylight variable incorrectly set - according to software vendor
Last modified: 2015-12-11 07:20:34 EST
The description of the daylight variable is somewhat vague.
In the libc info it says:
Variable: int daylight
This variable has a nonzero value if Daylight Saving Time rules apply. A nonzero value does not necessarily mean that Daylight Saving Time is now in effect; it means only that Daylight Saving Time is sometimes in effect.
In the tzset it is described twice, first as:
In a System-V-like environment, it will also set the variables timezone (seconds West of UTC) and daylight (to 0 if this timezone does not have any daylight saving time rules, or to nonzero if there is a time during the year when daylight saving time applies).
and later as:
Note that the variable daylight does not indicate that daylight saving time applies right now. It used to give the number of some algorithm (see the variable tz_dsttime in gettimeofday(2)). It has been obsolete for many years but is required by SUSv2.
I believe it is safe to assume that, how it is implemented in glibc,
is that, if set, it means there was daylight saving at some point in
the past, and there may be one in the future, including the current
year. So, it is just a hint that when computing time differences,
one must check where there was daylight time saving.
I think the only thing that is not much clear is about places that
never had a daylight saving, but somehow changed timezone. But this
may also be covered in case this only happened after the databases
Red Hat user also asked at
My comments above are also based on time/tzset.c chunk:
if (num_transitions == 0)
/* Use the first rule (which should also be the only one). */
rule_stdoff = rule_dstoff = types.offset;
int stdoff_set = 0, dstoff_set = 0;
rule_stdoff = rule_dstoff = 0;
i = num_transitions - 1;
if (!stdoff_set && !types[type_idxs[i]].isdst)
stdoff_set = 1;
rule_stdoff = types[type_idxs[i]].offset;
else if (!dstoff_set && types[type_idxs[i]].isdst)
dstoff_set = 1;
rule_dstoff = types[type_idxs[i]].offset;
if (stdoff_set && dstoff_set)
while (i-- > 0);
rule_dstoff = rule_stdoff;
__daylight = rule_stdoff != rule_dstoff;
where __daylight is an weak alias to daylight.
The glibc manual is clear on this point. If there has ever been, in the past, or future, a daylight saving rule for the zone, then daylight value will be non-zero. The timezone data contains past, prevent and future data and is as accurate as the most recent version of tzdata which you have installed on your system (overriden by your own custom rules in the TZ env var).
I submitted two patches upstream to the linux man pages project to clarify this:
[patch] gettimeofday.2: Expand on the historic historical meaning of tz_dsttime.
[patch] tzset.3: Clarify "daylight" and remove erroneous note.
I'm closing this as CLOSED/NOTABUG.
Many thanks Carlos.
I believe it is now clear as well, that if Linux has
any difference, it is very well documented, and it is
not that Linux and Solaris have a bug. But I am not
sure about, compared to what :)