Bug 1290533 - RFC: tzset daylight variable incorrectly set - according to software vendor
RFC: tzset daylight variable incorrectly set - according to software vendor
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
All All
low Severity low
: rc
: ---
Assigned To: Carlos O'Donell
Depends On:
  Show dependency treegraph
Reported: 2015-12-10 12:55 EST by Paulo Andrade
Modified: 2015-12-11 07:20 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-10 17:07:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paulo Andrade 2015-12-10 12:55:25 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
became "valid".

  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[0].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);

      if (!dstoff_set)
	rule_dstoff = rule_stdoff;

  __daylight = rule_stdoff != rule_dstoff;
where __daylight is an weak alias to daylight.
Comment 3 Carlos O'Donell 2015-12-10 17:07:23 EST
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.
Comment 4 Paulo Andrade 2015-12-11 07:20:34 EST
  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 :)

Note You need to log in before you can comment on or make changes to this bug.