[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