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.
Getting the update out quickly seems more important to me than modeling the exact sequence of transitions. You can always go back in and add the historical information in a subsequent release. Debbie
On Mar 27, 2023, at 11:11 AM, Paul Eggert via tz <tz@iana.org> wrote:
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. <0001-Revert-2023b-s-data-changes.patch>
Agree with the change, I don't think the government's decision to continue postponing DST until March 30 should be respected. This change most accurately reflects the reality in Lebanon (except for maybe one sector ATM) and does not violate the principle of least surprise when updating. Thank you for cleaning up this mess :) On 3/27/23 21:11, Paul Eggert via tz wrote:
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.
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@cs.ucla.edu> Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz@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.
The Prime Minister has stated that this was an "exceptional" decision solely for this year when referring to postponing DST for a month, so the decision to rollback that temporary change is definitely temporary as well. On 3/27/23 21:25, Andrea Singletary via tz wrote:
No word on what this means for next year, but I digress
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@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@cs.ucla.edu> Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz@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.
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@apple.com> Sent: Monday, March 27, 2023 1:29 PM To: Andrea Singletary <asinglet@epic.com> Cc: Time zone mailing list <tz@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@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@cs.ucla.edu> Sent: Monday, March 27, 2023 1:11 PM To: Time zone mailing list <tz@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.
I’m not a Microsoft representative, however I do have data to add to such a discussion. The C++20 language specification incorporates the IANA database into the C++ standard library. On all platforms but Windows this is a fairly light weight lift because said platforms already ship with the IANA database. Microsoft representatives agreed to this change in C++ and have implemented it by taking advantage of the IANA database that ships with ICU, which in turn ships on the latest Windows platforms. The C++20 spec also has a “current time zone” function which must translate the Windows currently set time zone into an IANA time zone identifier. I mention all this to reinforce Rich’s observation for the need for synchronization between these databases and to bring to attention additional motivations for such synchronization. Howard On Mar 27, 2023, at 4:35 PM, Rich Armstrong via tz <tz@iana.org> wrote:
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.
This is unfortunately complicated and most hospitals (and organizations in general) have not abided by the government's decision. I do not think it should be memorialized because that change wasn't even respected by the government itself when it comes to storing records on computers. For example, the Ministry of Finance and Education ignored the government's postponing of DST when storing information on computers (with the Education ministry ignoring it entirely) and I assume this was done by most if not all the government departments. So in a way, memorializing this change would actually cause issues NOT solve as old records created with an old tzinfo will break. On 3/27/23 21:25, Andrea Singletary via tz wrote:
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.
Andrea Singletary via tz <tz@iana.org> writes:
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.)
Meh. As I understand the theory here, the intention is to record the actual facts on the ground, that is what a person on the street would say the time is. Clearly, there is no single right answer to that question in this case. However, it's clear from the reports we saw that the governmental decision was *very* poorly received, and it seems plausible that the majority of the population ignored it. My vote is to keep things simple and revert to the 2023a data. As Deborah said, historical corrections can always be made later if the picture about what really happened clarifies. But we don't need any hasty decisions right now, and changing the 2023a data on the basis of the facts in hand sure seems hasty. regards, tom lane
participants (7)
-
Andrea Singletary -
Deborah Goldsmith -
Howard Hinnant -
Paul Eggert -
Rany Hany -
Rich Armstrong -
Tom Lane