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 2155352 - glibc: tzset() with TZ=Africa/Tripoli does not set daylight to 1
Summary: glibc: tzset() with TZ=Africa/Tripoli does not set daylight to 1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: glibc
Version: 9.1
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: Sergey Kolosov
Jacob Taylor Valdez
URL:
Whiteboard:
Depends On: 2160734
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-12-21 00:47 UTC by Takayuki Nagata
Modified: 2023-05-09 10:19 UTC (History)
11 users (show)

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.
Clone Of:
Environment:
Last Closed: 2023-05-09 08:16:03 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-142996 0 None None None 2022-12-21 01:01:18 UTC
Red Hat Product Errata RHBA-2023:2481 0 None None None 2023-05-09 08:16:21 UTC
Sourceware 29951 0 P2 ASSIGNED daylight variable not set correctly if last DST change coincides with offset change 2023-01-02 09:52:01 UTC

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
Note You need to log in before you can comment on or make changes to this bug.