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

[Rany Hany]

There is no consensus, even in the case of hospitals. For example, 
Hôtel-Dieu (USJ) and Bellevue did not abide by the change.

 > Hôtel-Dieu de France and its hospital network have decided to comply 
with DST tonight (25-26 March 2023).

Source: https://www.usj.edu.lb/news.php?id=13195

On 3/28/23 13:43, Andrea Singletary via tz wrote:
>
> Below my email is a message from my colleague Paige Tummons, who works 
> closely with hospitals and clinics in Lebanon. They are of the 
> position that the TZDB update needs to reflect DST in Lebanonbeginning 
> on the 30th.
>
> I understand that the goal of TZDB is to reflect the reality on the 
> ground, but the situation on the ground is not as clear-cut as it may 
> seem. Per my colleagues in Lebanon, people ARE still operating on 
> Standard Time, most of them having updated their phones to the Cairo 
> time zone to remain on UTC+2, with a plan to switch back on March 
> 30. In the absence of genuine consensus among the Lebanese people, I 
> argue that it's best for 2023c to codify the government's official 
> position that DSTbegins on the 30th.
>
> Best,
> Andrea
>
> ---
>
> From Paige Tummons:
>
> I’m reaching out regarding your request for comments 
> <https://mm.icann.org/pipermail/tz/2023-March/032833.html> on the 
> proposal to revert back to 2023a instead of updating 2023c to reflect 
> the Lebanon DST change of _30 March_. I’ve been working closely with 
> medical centers in Lebanon to ensure that their healthcare systems are 
> in continuous legal compliance with the government directives. We have 
> been in close communication with Lebanese government authorities who 
> legally consider the spring forward event to be _on 30 March_ (with 
> the jump being _from 11:59:59 PM on 29 March to 01:00:00 AM on 30 
> March_).
>
> We are strongly urging you to reflect this update in the 2023c file, 
> to avoid the published tzdata file being in direct conflict with the 
> government directive of the spring DST event in Lebanon happening_on 
> 30 March_. The Prime Minister met with the cabinet yesterday, and 
> together they agreed that Lebanon DST happens_on the 30^th of March_. 
> No government authorities consider the 26 March 2023 event to be the 
> “true” DST time for Lebanon.
>
> Thanks,
> Paige Tummons
>
> ------------------------------------------------------------------------
> *From:* Saadallah Itani <sitani at aub.edu.lb>
> *Sent:* Tuesday, March 28, 2023 5:02 AM
> *To:* Paul Eggert <eggert at cs.ucla.edu>; Andrea Singletary 
> <asinglet at epic.com>
> *Cc:* Time zone mailing list <tz at iana.org>; Maher Kassab 
> <maherk at aub.edu.lb>; Mohammad Abbass <mabbass at aub.edu.lb>; Deborah 
> Goldsmith <goldsmit at apple.com>
> *Subject:* [tz] Proposal to revert 2023b's Lebanon data changes
>
>
> External Mail
>
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20230328/056a21cb/attachment.htm>