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

Rany Hany rany_hany at riseup.net
Tue Mar 28 15:55:16 UTC 2023


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 at riseup.net>
> *Sent:* Tuesday, March 28, 2023 7:24 AM
> *To:* Jad Baz <jadbaz at gmail.com>
> *Cc:* Time zone mailing list <tz at 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 at 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/032833.html__;!!BJMh1g!_tmD-94p_mY-w8Tlt_j2__Ybjmrxyw0rfsuOBZxNHKyBnSHoeNUsHlGCkYBlcR_-qaImhQp59gEb7iHN$>
>             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>
>             <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
>             <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20230328/49adcb1f/attachment-0001.html>


More information about the tz mailing list