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

Tue Mar 28 10:47:52 UTC 2023

Dears,

Adding @Tim also just to make sure 2023-c should be only released in
alignment with the Government latest decision that the DST will happen on
March 30th based on yesterday' s decision.

From: Andrea Singletary <asinglet at epic.com> 
Sent: Tuesday, March 28, 2023 12:44 PM
To: Saadallah Itani <sitani at aub.edu.lb>; Paul Eggert <eggert at cs.ucla.edu>
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: Re: [tz] Proposal to revert 2023b's Lebanon data changes

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 Lebanon beginning 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 DST begins on the 30th. 

Best,
Andrea

---

>From Paige Tummons:

I'm reaching out regarding your
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.
org%2Fpipermail%2Ftz%2F2023-March%2F032833.html&data=05%7C01%7Csitani%40aub.
edu.lb%7Cdbe1c244cedc4ae5097708db2f795aec%7Cc7ba5b1a41b643e9a1206ff654ada137
%7C1%7C0%7C638155970509602026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3PU2o7o5L
ABgRNhv8mTYbdBmAyIUmtZR%2BVq8goohqx0%3D&reserved=0> request for comments 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 30thof 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 <mailto:sitani at aub.edu.lb> >
Sent: Tuesday, March 28, 2023 5:02 AM
To: Paul Eggert <eggert at cs.ucla.edu <mailto:eggert at cs.ucla.edu> >; Andrea
Singletary <asinglet at epic.com <mailto:asinglet at epic.com> >
Cc: Time zone mailing list <tz at iana.org <mailto:tz at iana.org> >; Maher Kassab
<maherk at aub.edu.lb <mailto:maherk at aub.edu.lb> >; Mohammad Abbass
<mabbass at aub.edu.lb <mailto:mabbass at aub.edu.lb> >; Deborah Goldsmith
<goldsmit at apple.com <mailto: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: <https://mm.icann.org/pipermail/tz/attachments/20230328/da59050b/attachment.html>
-------------- 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/da59050b/smime.p7s>