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.

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@epic.com> Sent: Tuesday, March 28, 2023 12:44 PM To: Saadallah Itani <sitani@aub.edu.lb>; Paul Eggert <eggert@cs.ucla.edu> Cc: Time zone mailing list <tz@iana.org>; Maher Kassab <maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb>; Deborah Goldsmith <goldsmit@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@aub.edu.lb <mailto:sitani@aub.edu.lb> > Sent: Tuesday, March 28, 2023 5:02 AM To: Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu> >; Andrea Singletary <asinglet@epic.com <mailto:asinglet@epic.com> > Cc: Time zone mailing list <tz@iana.org <mailto:tz@iana.org> >; Maher Kassab <maherk@aub.edu.lb <mailto:maherk@aub.edu.lb> >; Mohammad Abbass <mabbass@aub.edu.lb <mailto:mabbass@aub.edu.lb> >; Deborah Goldsmith <goldsmit@apple.com <mailto:goldsmit@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.

So this is quite a pickle I suggest we focus more on the impact than on official vs non-official. I say this especially in light of the minister's reason for keeping Winter time 3 more days: that it's a time window for institutions to revert to DST in case they changed Most IT systems did not implement any changes before the weekend and those that might have considered starting to change them Monday morning held off until the cabinet meeting. And then subsequently decided not to bother with implementing any changes for those 3 days Let's try to find out what systems changed and what systems did not Are there any large institutions that have set their IT systems on Winter time aside from AUBMC and the aiport? We know that the central bank kept DST for all transaction data (while employees clocked in on winter time) Following the central bank, all Lebanese banks kept their systems on DST I haven't heard of a hospital other than AUBMC that changed their local time to Winter time I feel that messing up all the country's financial records is very risky What's the risk involved in having 4 days of historical inaccuracies in EPIC records and local flight times On Tue, Mar 28, 2023, 13:57 Rany Hany via tz <tz@iana.org> wrote:

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 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 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 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@aub.edu.lb> <sitani@aub.edu.lb> *Sent:* Tuesday, March 28, 2023 5:02 AM *To:* Paul Eggert <eggert@cs.ucla.edu> <eggert@cs.ucla.edu>; Andrea Singletary <asinglet@epic.com> <asinglet@epic.com> *Cc:* Time zone mailing list <tz@iana.org> <tz@iana.org>; Maher Kassab <maherk@aub.edu.lb> <maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb> <mabbass@aub.edu.lb>; Deborah Goldsmith <goldsmit@apple.com> <goldsmit@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.

What did the airlines do? Historically, the TZDB has taken a lot of its info from the IATA Standard Schedules Information Manual. It's worth considering that as we attempt to reconcile this. From: Rany Hany <rany_hany@riseup.net> Sent: Tuesday, March 28, 2023 7:24 AM To: Jad Baz <jadbaz@gmail.com> Cc: Time zone mailing list <tz@iana.org> Subject: Re: [tz] Proposal to revert 2023b's Lebanon data changes Well said. I think this is on AUBMC for being too excited about postponing DST. I also think they're the only org that actually bothered and tried being compliant. Of course, technically they were doing the right thing and it was not totally foreseeable that it will be reverted but it should be said that they're the only ones with this issue. No need to inflict issues on everyone else because you were "responsible" and agreed to being bullied by the government. On 3/28/23 14:43, Jad Baz wrote: So this is quite a pickle I suggest we focus more on the impact than on official vs non-official. I say this especially in light of the minister's reason for keeping Winter time 3 more days: that it's a time window for institutions to revert to DST in case they changed Most IT systems did not implement any changes before the weekend and those that might have considered starting to change them Monday morning held off until the cabinet meeting. And then subsequently decided not to bother with implementing any changes for those 3 days Let's try to find out what systems changed and what systems did not Are there any large institutions that have set their IT systems on Winter time aside from AUBMC and the aiport? We know that the central bank kept DST for all transaction data (while employees clocked in on winter time) Following the central bank, all Lebanese banks kept their systems on DST I haven't heard of a hospital other than AUBMC that changed their local time to Winter time I feel that messing up all the country's financial records is very risky What's the risk involved in having 4 days of historical inaccuracies in EPIC records and local flight times On Tue, Mar 28, 2023, 13:57 Rany Hany via tz <tz@iana.org<mailto:tz@iana.org>> wrote: 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<https://urldefense.com/v3/__https:/www.usj.edu.lb/news.php?id=13195__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59hBKhj9u$> 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 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 request for comments<https://urldefense.com/v3/__https:/mm.icann.org/pipermail/tz/2023-March/0328...> 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@aub.edu.lb><mailto:sitani@aub.edu.lb> Sent: Tuesday, March 28, 2023 5:02 AM To: Paul Eggert <eggert@cs.ucla.edu><mailto:eggert@cs.ucla.edu>; Andrea Singletary <asinglet@epic.com><mailto:asinglet@epic.com> Cc: Time zone mailing list <tz@iana.org><mailto:tz@iana.org>; Maher Kassab <maherk@aub.edu.lb><mailto:maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb><mailto:mabbass@aub.edu.lb>; Deborah Goldsmith <goldsmit@apple.com><mailto:goldsmit@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<https://urldefense.com/v3/__http:/cs.ucla.edu__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59mMckfPt$>> Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz at iana.org<https://urldefense.com/v3/__http:/iana.org__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59neaJGY-$>> 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.

Maybe I should have been clearer. If MEA stated that they will land at 2PM EEST, they just pushed it by an hour to instead be 3PM EET. Hope that clears it up. On 3/28/23 18:55, Rany Hany via tz wrote:

The airlines simply adjusted their time one hour into the future to "postpone DST." So in effect nothing changed relative to UTC.

On 3/28/23 18:53, Andrea Singletary wrote:

...

What did the airlines do? Historically, the TZDB has taken a lot of its info from the IATA Standard Schedules Information Manual. It’s worth considering that as we attempt to reconcile this.

*From:* Rany Hany <rany_hany@riseup.net> *Sent:* Tuesday, March 28, 2023 7:24 AM *To:* Jad Baz <jadbaz@gmail.com> *Cc:* Time zone mailing list <tz@iana.org> *Subject:* Re: [tz] Proposal to revert 2023b's Lebanon data changes

Well said. I think this is on AUBMC for being too excited about postponing DST. I also think they're the only org that actually bothered and tried being compliant.

Of course, technically they were doing the right thing and it was not totally foreseeable that it will be reverted but it should be said that they're the only ones with this issue. No need to inflict issues on everyone else because you were "responsible" and agreed to being bullied by the government.

On 3/28/23 14:43, Jad Baz wrote:

So this is quite a pickle

I suggest we focus more on the impact than on official vs non-official. I say this especially in light of the minister's reason for keeping Winter time 3 more days: that it's a time window for institutions to revert to DST in case they changed

Most IT systems did not implement any changes before the weekend and those that might have considered starting to change them Monday morning held off until the cabinet meeting. And then subsequently decided not to bother with implementing any changes for those 3 days

Let's try to find out what systems changed and what systems did not

Are there any large institutions that have set their IT systems on Winter time aside from AUBMC and the aiport?

We know that the central bank kept DST for all transaction data (while employees clocked in on winter time)

Following the central bank, all Lebanese banks kept their systems on DST

I haven't heard of a hospital other than AUBMC that changed their local time to Winter time

I feel that messing up all the country's financial records is very risky

What's the risk involved in having 4 days of historical inaccuracies in EPIC records and local flight times

On Tue, Mar 28, 2023, 13:57 Rany Hany via tz <tz@iana.org> wrote:

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 <https://urldefense.com/v3/__https:/www.usj.edu.lb/news.php?id=13195__;!!BJMh...>

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 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 request for comments <https://urldefense.com/v3/__https:/mm.icann.org/pipermail/tz/2023-March/0328...> 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@aub.edu.lb> <mailto:sitani@aub.edu.lb> *Sent:* Tuesday, March 28, 2023 5:02 AM *To:* Paul Eggert <eggert@cs.ucla.edu> <mailto:eggert@cs.ucla.edu>; Andrea Singletary <asinglet@epic.com> <mailto:asinglet@epic.com> *Cc:* Time zone mailing list <tz@iana.org> <mailto:tz@iana.org>; Maher Kassab <maherk@aub.edu.lb> <mailto:maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb> <mailto:mabbass@aub.edu.lb>; Deborah Goldsmith <goldsmit@apple.com> <mailto:goldsmit@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 <https://urldefense.com/v3/__http:/cs.ucla.edu__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59mMckfPt$>>

Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz at iana.org <https://urldefense.com/v3/__http:/iana.org__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59neaJGY-$>>

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.

As I mentioned earlier there are good reasons to not split TZDB Zones in this case. So the choice here is between having 2023c simply revert to 2023a (following one set of users and one interpretation of the law), or have 2023c reflect the prime minister's current spring-forward of March 29/30 (following another set of users with a different legal interpretation - perhaps using "BMT" as an abbreviation? though this would need further discussion).

Reverting to 2023a has the virtue of simplicity for TZDB distributors and users, and where there's genuine uncertainty simpler is often better. Although this simplicity will inconvenience many users it seems like it is the best of a bunch of bad options.

By the time 2023c is distributed to people it will already be past the new transition time of midnight Wednesday. The behavior now is only of historical interest. Debbie

On Mar 28, 2023, at 11:46 AM, Paul Eggert via tz <tz@iana.org> wrote:

On 2023-03-28 08:53, Andrea Singletary via tz wrote:

...

What did the airlines do?

As I understand it, airlines launched and landed planes as if the prime minister's change had not happened, and Beirut–Rafic Hariri International Airport posted two times for each flight, one using the prime minister's change, one without. Reuters reporter Timour Azhari tweeted about an airport time wormhole, passed along in The Register's Thomas Claburn's "Lebanon's IT folks face double trouble as leaders delayed Daylight Savings Time" <https://www.theregister.com/2023/03/28/lebanon_dst_delay_chaos/>:

...

Azhari recounted passing through passport control at Beirut International Airport at 1200 GMT and, by virtue of inconsistent time keeping, boarding his flight 30 minutes prior to his security check, at 1130 BMT.

No matter what TZDB does, many uses on the ground will disagree and it's hard to judge which timekeeping is more popular. In today's "Lebanon fails the test of time" <https://www.ft.com/content/4788ed25-e925-4851-bf37-61699db5987a> Financial Times reporter Raya Jalabi wrote:

...

“Our leaders have already broken everything in this country. I guess they got bored and decided to break time itself,” said Mohammad Sharif, a street vendor in Beirut, hawking corn. Sharif said he would be keeping “Berri Mikati Time” (BMT, henceforth) as he’s fasting, unlike the frame shop owner next door, who said he would roll his clocks forward. “Lebanon is so democratic, every business can choose its own time zone,” Sharif said, echoing a joke that made the rounds on social media over the weekend.

As I mentioned earlier there are good reasons to not split TZDB Zones in this case. So the choice here is between having 2023c simply revert to 2023a (following one set of users and one interpretation of the law), or have 2023c reflect the prime minister's current spring-forward of March 29/30 (following another set of users with a different legal interpretation - perhaps using "BMT" as an abbreviation? though this would need further discussion).

Reverting to 2023a has the virtue of simplicity for TZDB distributors and users, and where there's genuine uncertainty simpler is often better. Although this simplicity will inconvenience many users it seems like it is the best of a bunch of bad options.

Dear Paul, Can you just release 2023-c based on the government decision yesterday which is the official and align with the government statement yesterday and comment its description for history records? Its chaos all over as Red Hat released 2023-b and apple and other vendors follows… Thanks you Regards, Saad Ext. 2229 Sent from my iPhone

On 28 Mar 2023, at 8:57 PM, Paul Eggert via tz <tz@iana.org> wrote:

On 2023-03-28 11:48, Debbie Goldsmith wrote:

...

By the time 2023c is distributed to people it will already be past the new transition time of midnight Wednesday. The behavior now is only of historical interest.

That's correct if you're currently using 2023a which is what I have recommended. However, if you're currently using 2023b you will need to update to 2023c (or downgrade to 2023a) as soon as possible, as 2023b says that Lebanon observes standard time until April 20/21. If you use 2023b, both sides of the Lebanese dispute will disagree with you from March 30 through April 20.

We'd all have been better off if we had never released TZDB 2023b. Hindsight is wonderful, no?

Yet another option is to wait until after the March 29/30 transition and then release 2023c as a duplicate of 2023a. This would have a different set of problems, which I hope are obvious; surely this option would be worse than rolling back to 2023a today.

I think it would be fine to release 2023c right now as a duplicate of 2023a and then add historical detail about the period between Saturday and Wednesday in a future version which doesn’t need to be released immediately or even soon. Debbie

On Mar 28, 2023, at 12:22 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

On 2023-03-28 12:11, Saadallah Itani wrote:

...

Can you just release 2023-c based on the government decision yesterday which is the official and align with the government statement yesterday and comment its description for history records?

Yes, that is an option. The problem, though, is that there is genuine disagreement on the ground as to what rules should be followed, whether the prime minister's announcement last week was legal, how today's timestamps in hospitals and banks and etc. should be interpreted, and so forth. And generating such a 2023c would involve making further decisions, such as what abbreviation to use for these timestamps - would they be "BMT" or "EET"? and if they're "BMT" wouldn't that break some existing software?

Yet another option is to wait until after the March 29/30 transition and then release 2023c as a duplicate of 2023a. This would have a different set of problems, which I hope are obvious; surely this option would be worse than rolling back to 2023a today.

Thank you Paul, Debbie, Andrea for your time and effort. I hope the government or future government including the Lebanese people learn not to mess with timezones in a short notice. Regards, Saad Ext. 2229 Sent from my iPhone

On 28 Mar 2023, at 9:49 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 2023-03-28 12:28, Debbie Goldsmith wrote:

...

I think it would be fine to release 2023c right now as a duplicate of 2023a and then add historical detail about the period between Saturday and Wednesday in a future version which doesn’t need to be released immediately or even soon.

Works for me. I'll look into cutting a new release.

Thank you Andrea for following up and for the spotify playlist :) Note that there is also a humor Youtube trailer about DST https://youtu.be/k4EUTMPuvHo Enjoy Regards, Saad Ext. 2229 Sent from my iPhone

On 28 Mar 2023, at 11:14 PM, Andrea Singletary <asinglet@epic.com> wrote:

Thank you to all of you for your input, especially to our friends in Lebanon for giving us a picture of the state of affairs in real-time. Thanks also to Paul & Tim for the quick turnaround. I look forward to continued debate about how to handle the "four days of limbo" after 2023c ships and we've all taken a nice break.

I made us a Spotify playlist to commemorate the occasion. Enjoy. https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen.spoti...

-Andrea

-----Original Message----- From: Saadallah Itani <sitani@aub.edu.lb> Sent: Tuesday, March 28, 2023 2:55 PM To: Paul Eggert <eggert@cs.ucla.edu> Cc: Debbie Goldsmith <goldsmit@apple.com>; Time zone mailing list <tz@iana.org>; Andrea Singletary <asinglet@epic.com>; Maher Kassab <maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb> Subject: Re: [tz] Proposal to revert 2023b's Lebanon data changes

External Mail

Thank you Paul, Debbie, Andrea for your time and effort.

I hope the government or future government including the Lebanese people learn not to mess with timezones in a short notice.

Regards, Saad Ext. 2229

Sent from my iPhone

...

...

On 28 Mar 2023, at 9:49 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

?On 2023-03-28 12:28, Debbie Goldsmith wrote: I think it would be fine to release 2023c right now as a duplicate of 2023a and then add historical detail about the period between Saturday and Wednesday in a future version which doesn't need to be released immediately or even soon.

Works for me. I'll look into cutting a new release.

Addng a message below that I received that doesn't appear to have gone to the entire list. I don't know this person; I'm just trying to make sure the group sees his comment. From: Jack Bakaev Jack.Bakaev@isoc.org.lb<mailto:Jack.Bakaev@isoc.org.lb> Sent: Tuesday, March 28, 2023 7:08 AM To: eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>; Andrea Singletary asinglet@epic.com<mailto:asinglet@epic.com> Cc: tz@iana.org<mailto:tz@iana.org> Subject: External Mail. Careful of links / attachments. Submit Helpdesk if unsure. Hello, Lebanon decided to postpone the DST till end of April instead of march 25-26 TZ complied then the cabinet of Ministers in Lebanon decided yesterday March 27 to revert to DST during the night of March 29-30. please do not revert Lebanon DST back to March 25-26! this will cause problems for those who who already complied with the postponement please revert to DST during the night of March 29-30. Jack Bakaev Internet Society - Lebanon Chapter Chapter Secretary From: Jad Baz <jadbaz@gmail.com> Sent: Tuesday, March 28, 2023 6:44 AM To: Rany Hany <rany_hany@riseup.net> Cc: Time zone mailing list <tz@iana.org> Subject: Re: [tz] Proposal to revert 2023b's Lebanon data changes So this is quite a pickle I suggest we focus more on the impact than on official vs non-official. I say this especially in light of the minister's reason for keeping Winter time 3 more days: that it's a time window for institutions to revert to DST in case they changed Most IT systems did not implement any changes before the weekend and those that might have considered starting to change them Monday morning held off until the cabinet meeting. And then subsequently decided not to bother with implementing any changes for those 3 days Let's try to find out what systems changed and what systems did not Are there any large institutions that have set their IT systems on Winter time aside from AUBMC and the aiport? We know that the central bank kept DST for all transaction data (while employees clocked in on winter time) Following the central bank, all Lebanese banks kept their systems on DST I haven't heard of a hospital other than AUBMC that changed their local time to Winter time I feel that messing up all the country's financial records is very risky What's the risk involved in having 4 days of historical inaccuracies in EPIC records and local flight times On Tue, Mar 28, 2023, 13:57 Rany Hany via tz <tz@iana.org<mailto:tz@iana.org>> wrote: 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<https://urldefense.com/v3/__https:/www.usj.edu.lb/news.php?id=13195__;!!BJMh1g!8eruCA_CbnB_qNx7LBJAoctx0Zx4-5ikPH--oAATELAntXhnH0pJPZQfOJLxX03YKOdrY1Ug_PmSlW5f$> 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 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 request for comments<https://urldefense.com/v3/__https:/mm.icann.org/pipermail/tz/2023-March/0328...> 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@aub.edu.lb><mailto:sitani@aub.edu.lb> Sent: Tuesday, March 28, 2023 5:02 AM To: Paul Eggert <eggert@cs.ucla.edu><mailto:eggert@cs.ucla.edu>; Andrea Singletary <asinglet@epic.com><mailto:asinglet@epic.com> Cc: Time zone mailing list <tz@iana.org><mailto:tz@iana.org>; Maher Kassab <maherk@aub.edu.lb><mailto:maherk@aub.edu.lb>; Mohammad Abbass <mabbass@aub.edu.lb><mailto:mabbass@aub.edu.lb>; Deborah Goldsmith <goldsmit@apple.com><mailto:goldsmit@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<https://urldefense.com/v3/__http:/cs.ucla.edu__;!!BJMh1g!8eruCA_CbnB_qNx7LBJAoctx0Zx4-5ikPH--oAATELAntXhnH0pJPZQfOJLxX03YKOdrY1Ug_MP8E2_4$>> Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz at iana.org<https://urldefense.com/v3/__http:/iana.org__;!!BJMh1g!8eruCA_CbnB_qNx7LBJAoctx0Zx4-5ikPH--oAATELAntXhnH0pJPZQfOJLxX03YKOdrY1Ug_OZGmVKZ$>> 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.

I also find xkcd 2347 - "Dependency" to be highly relevant. https://xkcd.com/2347/ -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Tuesday, March 28, 2023 3:31 AM To: Deborah Goldsmith <goldsmit@apple.com> Cc: Time zone mailing list <tz@iana.org> Subject: Re: [tz] [PROPOSED 2/2] Fix comments on Lebanon this week On 2023-03-27 21:55, Deborah Goldsmith wrote:

Do you know if any further changes are planned for 2023c?

No further data changes are planned. That is, 2023c is planned to be the same as 2023a, except for commentary. Before issuing 2023c I want to wait a few more hours for responses to that idea, which was circulated on this list. In an attempt to see the lighter side of the situation I installed into the development repository the attached patch to commentary. This adds four xkcd panels to our humor section: "Good Morning"[1], "Consensus New Year"[2], "Edge Cake"[3], and "Consensus Time"[4]. If cartoonist Randall Munroe lurks on this list, perhaps he'll add a panel about Lebanon's time chaos some day. This patch also refers to Emanuele Arciuli's recent recording[5] of the first twelve parts of The Time Curve Preludes[6], a piano cycle composed in 1977/8 by William Duckworth[7]. I heard part of this cycle for the first time yesterday when listening to the March 20 broadcast of Alley Stoughton's radio show "Not Brahms and Liszt"[8] on MIT's station WMBR 88.1 FM. That broadcast recording[9] is available for the next six days in the show's archive, if you'd like to listen too. The selection from The Time Curve Preludes is the third piece in the show, and I found it a welcome relief from this week's time chaos. [1]: https://xkcd.com/673/ [2]: https://xkcd.com/2092/ [3]: https://xkcd.com/2549/ [4]: https://xkcd.com/2594/ [5]: https://neumarecords.org/ols/products/william-duckworth-the-time-curve-prelu... [6]: https://en.wikipedia.org/wiki/The_Time_Curve_Preludes [7]: https://en.wikipedia.org/wiki/William_Duckworth_(composer) [8]: https://alleystoughton.us/not-brahms-and-liszt/ [9]: https://www.dropbox.com/s/ncpafxdcvhb2bro/Not_Brahms_and_Liszt_2023_03_20_AS...