Asia/Gaza POSIX TZ string problem
Hi, We obtained the *tzdata2024a* from IANA. Below is the Rule for *Asia/Gaza* extracted from *tzdata2024a*: * ...* *Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -* *Rule Palestine 2023 only - Apr 29 2:00 1:00 S* *Rule Palestine 2024 only - Apr 20 2:00 1:00 S* *Rule Palestine 2025 only - Apr 12 2:00 1:00 S* ... *Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST, M3.4.4/50,M10.4.4/50" The rule specifies that DST in 2024 starts on April 20th. Why then does the POSIX TZ string use M3.4.4? Is this a bug? or is there any other reason? Thanks. Best regards, Meng Chen
On 2024-04-18 00:50, Z Meng Chen via tz wrote:
*Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST, M3.4.4/50,M10.4.4/50"
POSIX TZ strings cannot exactly represent timekeeping in Palestine, so TZif files make do with an approximation. In the approximation, that TZ string should be used only for timestamps after the last transition in the TZif file. The last transition is 3686425200 seconds after 1970-01-01 00:00:00, not counting leap seconds, which is equivalent to 2086-10-25 23:00:00 in predicted Gaza time. This corresponds to the comment "Predictions after 2086 are approximated without Ramadan" in the 'asia' source file. To some extent the prediction is arbitrary, of course; nobody really knows what timekeeping in Gaza will be like even next year, much less after the year 2086.
On 2024-04-18 01:50, Z Meng Chen via tz wrote:
We obtained the *tzdata2024a* from IANA. Below is the Rule for *Asia/Gaza* extracted from *tzdata2024a*:
/ .../ /Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -/ /Rule Palestine 2023 only - Apr 29 2:00 1:00 S/ /Rule Palestine 2024 only - Apr 20 2:00 1:00 S/ /Rule Palestine 2025 only - Apr 12 2:00 1:00 S/
...
*Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST,M3.4.4/50,M10.4.4/50"
The rule specifies that DST in 2024 starts on April 20th. Why then does the POSIX TZ string use M3.4.4? Is this a bug? or is there any other reason? Thanks.
Hi Meng Chen, Have you checked the tzset(3) docs for TZ? IIRC these say after the specific rules up to 2086, use alternative standard+1 from March 4th Thursday at 50h UTC offset, reset to standard UTC+2 from October 4th Thursday at 50h UTC offset => Saturday after 4th Thursday at 02:00. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
On 2024-04-18 13:00, brian.inglis--- via tz wrote:
On 2024-04-18 01:50, Z Meng Chen via tz wrote:
We obtained the *tzdata2024a* from IANA. Below is the Rule for *Asia/Gaza* extracted from *tzdata2024a*: / .../ /Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -/ /Rule Palestine 2023 only - Apr 29 2:00 1:00 S/ /Rule Palestine 2024 only - Apr 20 2:00 1:00 S/ /Rule Palestine 2025 only - Apr 12 2:00 1:00 S/ *Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST,M3.4.4/50,M10.4.4/50" The rule specifies that DST in 2024 starts on April 20th. Why then does the POSIX TZ string use M3.4.4? Is this a bug? or is there any other reason? Thanks.
Have you checked the tzset(3) docs for TZ? IIRC these say after the specific rules up to 2086, use alternative standard+1 from March 4th Thursday at 50h UTC offset, reset to standard UTC+2 from October 4th Thursday at 50h UTC offset => Saturday after 4th Thursday at 02:00.
Sorry - sent and forgot to paste in the last specific rules for the future: ... Rule Palestine 2059 max - Mar Sat<=30 2:00 1:00 S ... Rule Palestine 2072 max - Oct Sat<=30 2:00 0 - ... other rules are similar for earlier ranges or single year exceptions including for Ramadan. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
To try to document the problem with using only the POSIX TZ string, I installed the attached proposed patch.
participants (3)
-
brian.inglis＠systematicsw.ab.ca -
Paul Eggert -
Z Meng Chen