[tz] Lebanon DST change internally disputed

[Paul Eggert]

On 2023-03-25 15:12, Jad Baz via tz wrote:
> I'm wondering how transactions, meeting times and
> any sort of dealing with anyone outside Lebanon will take place when, say,
> one party is on 2023b while the other is still on 2022g

It's a mess indeed. I imagine that most automated clocks in Lebanon 
switched about 50 minutes ago, following the old rules and ignoring the 
rule change. And we're seeing many reports of institutions either 
ignoring the rule change, or maintaining two distinct clocks for 
different use cases.

To work around some of the TZDB part of the mess, here is what people in 
Lebanon can do, regardless of which TZDB release is installed.

* To adopt the rule change, use Libyan time (TZ='Africa/Tripoli'). 
Alternatively if you have a POSIX-conforming system you can use 
TZ='EET-2EEST,M4.3.5/0,M10.5.0/0' instead.

* To ignore the rule change, use Cyprus time (TZ='Asia/Nicosia'), which 
is close to the old rules (though it changes clocks at 03:00 instead of 
00:00 so it won't start working until about two hours and 10 minutes 
from now. Alternatively if you have POSIX use 
TZ='EET-2EEST,M3.5.0/0,M10.5.0/0', which doesn't have the early-morning 
glitch that Cyprus does.

None of these workarounds are good indefinitely; for example, if you 
want to adopt the rule change, Libya time will stop working on April 21. 
These are only temporary workarounds, intended for use on systems where 
you don't know the TZDB version.

I hope things settle down soon with a consensus in Lebanon. If the 
consensus is to keep using the old rules, we'll need a new TZDB release 
of course.