RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1290533 - RFC: tzset daylight variable incorrectly set - according to software vendor
Summary: RFC: tzset daylight variable incorrectly set - according to software vendor
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.8
Hardware: All
OS: All
low
low
Target Milestone: rc
: ---
Assignee: Carlos O'Donell
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-10 17:55 UTC by Paulo Andrade
Modified: 2019-09-12 09:32 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-10 22:07:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


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