Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
.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.
DescriptionTakayuki 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
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.
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
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