Bug 1290533

Summary: RFC: tzset daylight variable incorrectly set - according to software vendor
Product: Red Hat Enterprise Linux 6 Reporter: Paulo Andrade <pandrade>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED NOTABUG QA Contact: qe-baseos-tools-bugs
Severity: low Docs Contact:
Priority: low    
Version: 6.8CC: ashankar, fweimer, mnewsome, mpoole, pfrankli
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-10 22:07:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paulo Andrade 2015-12-10 17:55:25 UTC
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:

"""
NOTES
       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
http://stackoverflow.com/questions/33992832/tzset-and-daylight-global-variable-interpretation-in-time-h

  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;
  else
    {
      int stdoff_set = 0, dstoff_set = 0;
      rule_stdoff = rule_dstoff = 0;
      i = num_transitions - 1;
      do
	{
	  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)
	    break;
	}
      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 22:07:23 UTC
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.
http://marc.info/?l=linux-man&m=144977768703615&w=2

[patch] tzset.3: Clarify "daylight" and remove erroneous note.
http://marc.info/?l=linux-man&m=144978510505736&w=2

I'm closing this as CLOSED/NOTABUG.

Comment 4 Paulo Andrade 2015-12-11 12:20:34 UTC
  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 :)