Bug 2155352

Summary: glibc: tzset() with TZ=Africa/Tripoli does not set daylight to 1
Product: Red Hat Enterprise Linux 9 Reporter: Takayuki Nagata <tnagata>
Component: glibcAssignee: glibc team <glibc-bugzilla>
Status: CLOSED ERRATA QA Contact: Sergey Kolosov <skolosov>
Severity: unspecified Docs Contact: Jacob Taylor Valdez <jvaldez>
Priority: unspecified    
Version: 9.1CC: ashankar, codonell, dj, fweimer, jvaldez, kmoriwak, markobri, mnewsome, pfrankli, sipoyare, skolosov
Target Milestone: rcKeywords: Bugfix, Patch, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.34-57.el9 Doc Type: Bug Fix
Doc Text:
.The `tzset` function in `glibc` now sets the daylight variable to a non-zero value if there is any DST rule in the TZ data Previously, the `tzset` function in `glibc` would set the daylight variable to 0 if the last DST transition in the time zone data file did not result in a clock change due to a simultaneous change in the standard time offset. Consequently, when applications use the daylight variable to check if DST was ever active, they do not get the right result and perform incorrect actions based on this information. To fix this, the `tzset` function now sets the daylight variable to a non-zero value if there is any DST rule in the time zone data, regardless of offset. As a result, applications now observe the presence of DST rules regardless of offset changes.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-09 08:16:03 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:
Bug Depends On: 2160734    
Bug Blocks:    

Description Takayuki Nagata 2022-12-21 00:47:23 UTC 
Description of problem:

tzset() with TZ=Africa/Tripoli does not set daylight to 1.

[root@localhost ~]# cat tzset_test.c
#include <stdio.h>
#include <time.h>

void main(void)
{
	tzset();
	printf("daylight=%d\n", daylight);
}
[root@localhost ~]# make tzset_test
cc     tzset_test.c   -o tzset_test
[root@localhost ~]# TZ=Africa/Tripoli ./tzset_test 
daylight=0

Version-Release number of selected component (if applicable):
glibc-2.34-40.el9
tzdata-2022g-1.el9_1

How reproducible:
Always

Steps to Reproduce:
1. Run above tzset_test with TZ=Africa/Tripoli.
2.
3.

Actual results:
daylight=0

Expected results:
daylight=1

Additional info:

It appears to me that the tzfile has dst rules.

[root@localhost ~]# zdump -v /usr/share/zoneinfo/Africa/Tripoli | tail -n 5
/usr/share/zoneinfo/Africa/Tripoli  Fri Mar 29 00:00:00 2013 UT = Fri Mar 29 02:00:00 2013 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Africa/Tripoli  Thu Oct 24 23:59:59 2013 UT = Fri Oct 25 01:59:59 2013 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Africa/Tripoli  Fri Oct 25 00:00:00 2013 UT = Fri Oct 25 02:00:00 2013 EET isdst=0 gmtoff=7200
/usr/share/zoneinfo/Africa/Tripoli  9223372036854689407 = NULL
/usr/share/zoneinfo/Africa/Tripoli  9223372036854775807 = NULL
Comment 10 Florian Weimer 2023-01-05 17:52:58 UTC 
Fixed upstream:

commit 35141f304e319109c322f797ae71c0b9420ccb05
Author: Florian Weimer <fweimer>
Date:   Thu Jan 5 18:21:25 2023 +0100

    time: Set daylight to 1 for matching DST/offset change (bug 29951)
    
    The daylight variable is supposed to be set to 1 if DST is ever in
    use for the current time zone.  But __tzfile_read used to do this:
    
      __daylight = rule_stdoff != rule_dstoff;
    
    This check can fail to set __daylight to 1 if the DST and non-DST
    offsets happen to be the same.
Comment 21 errata-xmlrpc 2023-05-09 08:16:03 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (glibc bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2481