[tz] Proposal to revert 2023b's Lebanon data changes
eggert at cs.ucla.edu
Tue Mar 28 18:46:28 UTC 2023
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"
> 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"
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.
More information about the tz