[tz] Proposal to revert 2023b's Lebanon data changes

Saadallah Itani sitani at aub.edu.lb
Tue Mar 28 10:01:54 UTC 2023


Dear Paul,

Its very important to make sure you change on Github the "Asia file- Lebanon
section" and commit the Decision taken by the cabinet of Ministers in
Lebanon Government yesterday  March 27  that states the revert to DST will
happen on  March 30.  As we saw on tz git code that you commented the Rule
and its ineffective for the new file 2023-c.



"As quoted by Andrea from EPIC health systems:

I highly recommend "recording the chaos in more detail in the data" as the
approach here. The Lebanese government has clarified that for them,
DST/summer time in 2023 begins on March 30, with the clocks going from
23:59:59 March 29 to 01:00:00 March 30. (No word on what this means for next
year, but I digress.)

It's important that this be memorialized correctly because the systems that
depend on it include health systems that feed vital records databases. A
baby born in Beirut at 21:30 UTC on March 27 will be born at 23:30 local
Beirut time, and its birthday will be March 27. If we simply revert to
version 2023a, that would not sync up with the government, so the baby's
birthday might be recorded as 00:30 on March 28 in health system records,
which would not align with the government's opinion on the baby's date of
birth. 

Maybe it's just the historian in me, but I firmly believe we need to
memorialize this blip in the database.

Thanks,
Andrea
"


-----Original Message-----
From: Paul Eggert <eggert at cs.ucla.edu> 
Sent: Monday, March 27, 2023 1:11 PM
To: Time zone mailing list <tz at iana.org>
Subject: [tz] Proposal to revert 2023b's Lebanon data changes

We need a new release soon to address the time zone chaos in Lebanon. 
One option is to revert 2023b's data and go back to 2023a as I suggested
earlier. Another is to record the chaos in more detail in the data. The
attached proposed patch (which I installed into the developmental repository
on GitHub) takes the former approach, as I expect the latter would cause
more problems than it would cure. This follows a similar (although not
identical) precedent in Rio de Janeiro in 1993.

In short, the patch would make 2023c identical to 2023a except for comments,
which do not count as part of the data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2628 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20230328/753ae6ed/smime.p7s>


More information about the tz mailing list