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.
Description of problem:
Hello,
during development of application, one of our developers found that Africa/Casablanca timezone file is not conformant to the version 2. tzinfo manual page says:
...
Version 3 format
For version-3-format timezone files, the POSIX-TZ-style string may use two minor
extensions to the POSIX TZ format, as described in newtzset(3). First, the hours
part of its transition times may be signed and range from -167 through 167 instead of
the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all
year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the differ‐
ence between daylight saving and standard time.
...
Which he interprets that version 2 transition times must be in range 0 - 24, which is not true for Africa/Casablanca
Version-Release number of selected component (if applicable):
tzdata-2021e-1.el8.noarch
How reproducible:
# file /usr/share/zoneinfo/Africa/Casablanca
/usr/share/zoneinfo/Africa/Casablanca: timezone data, version 2, 5 gmt time flags, 5 std time flags, no leap seconds, 95 transition times, 5 abbreviation chars
# head -n 2 /usr/share/zoneinfo/Africa/Casablanca | tail -n 1
<+00>0<+01>,0/0,J365/25
where /25 is hours, which is supposed to be in range 0-24. Can you please fix this somehow, either by saying that Casablanca TZ is version 3 file, or by ensure that hours is in 0-24 range?
If you need any more information, feel free to tell me.
Thank you in advance!
Steps to Reproduce:
1. file /usr/share/zoneinfo/Africa/Casablanca
2. head -n 2 /usr/share/zoneinfo/Africa/Casablanca | tail -n 1
Actual results:
Non-conformant version 2 Casablanca TZ
Expected results:
Casablanca TZ file conforms to either version 2 timezone spec (0-24 hours) or it is converted to version 3
Hi,
Thanks for reporting this.
This is not reproducible with the current version of tzdata - tzdata-2022a.
tzdata-2022a no longer appears to use 25:00 in the TZ string.
Please upgrade to tzdata-2022a. If you are still able to reproduce this please reopen this bug.
Thank You,
Patsy
Description of problem: Hello, during development of application, one of our developers found that Africa/Casablanca timezone file is not conformant to the version 2. tzinfo manual page says: ... Version 3 format For version-3-format timezone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in newtzset(3). First, the hours part of its transition times may be signed and range from -167 through 167 instead of the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the differ‐ ence between daylight saving and standard time. ... Which he interprets that version 2 transition times must be in range 0 - 24, which is not true for Africa/Casablanca Version-Release number of selected component (if applicable): tzdata-2021e-1.el8.noarch How reproducible: # file /usr/share/zoneinfo/Africa/Casablanca /usr/share/zoneinfo/Africa/Casablanca: timezone data, version 2, 5 gmt time flags, 5 std time flags, no leap seconds, 95 transition times, 5 abbreviation chars # head -n 2 /usr/share/zoneinfo/Africa/Casablanca | tail -n 1 <+00>0<+01>,0/0,J365/25 where /25 is hours, which is supposed to be in range 0-24. Can you please fix this somehow, either by saying that Casablanca TZ is version 3 file, or by ensure that hours is in 0-24 range? If you need any more information, feel free to tell me. Thank you in advance! Steps to Reproduce: 1. file /usr/share/zoneinfo/Africa/Casablanca 2. head -n 2 /usr/share/zoneinfo/Africa/Casablanca | tail -n 1 Actual results: Non-conformant version 2 Casablanca TZ Expected results: Casablanca TZ file conforms to either version 2 timezone spec (0-24 hours) or it is converted to version 3