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

[Rich Armstrong]

Though this list usually doesn't include discussion of the time-zone-rule data that Microsoft maintains in the Windows registry, it seems worth considering how to ensure the two repositories of time-zone rules might be kept in sync regarding the recent time change(s) in Lebanon-not to mention IATA's repository. Thoughts and opinions from any MS representatives would be welcome.

(Incidentally, I was born at 11:50 PM at a place and time when hospitals recorded births on standard time even though the general population observed DST. Consequently, I reserve the right to celebrate my birthday on the 12th and/or 13th of the month I was born in.)

-----Original Message-----
From: Deborah Goldsmith <goldsmit at apple.com> 
Sent: Monday, March 27, 2023 1:29 PM
To: Andrea Singletary <asinglet at epic.com>
Cc: Time zone mailing list <tz at iana.org>
Subject: Re: [tz] Proposal to revert 2023b's Lebanon data changes

I have no objection to recording this in the DB but I think it can wait until a future release (2022d or whatever the next release is).

Debbie

> On Mar 27, 2023, at 11:25 AM, Andrea Singletary via tz <tz at iana.org> wrote:
> 
> 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.
> 
> It is a confusing and controversial situation. Comments welcome. In the meantime I again suggest to downstream distributors to stick with 2023a and avoid 2023b.
>