Bug 2054175
| Summary: | Africa/Casablanca timezone file is not conformant to version 2 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Adam Tkac <vonsch> |
| Component: | tzdata | Assignee: | Patsy Griffin <pfrankli> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, codonell, igor.raits, jan.kruza, jwboyer, sipoyare |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-06-22 02:24:34 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: | |||
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