Hacker News new | ask | show | jobs
by rchard2scout 1175 days ago
Since this only seems to happen in Ireland, could it be because Ireland technically has summer time as its standard time, and winter time as negative DST? Not sure how that's implemented in tzdata, but it could very well be that some applications can't handle that.
4 comments

Here's the tzdata: https://github.com/eggert/tz/blob/71faa2a55db2c9f21f4099b58c...

Looks like the negative DST has already caused problems in the past and applications that can't handle it (ICU & OpenJDK) have to build tzdata as per the rearguard section / ziguard.awk.

I have to say these time zone files are fascinating. Any place/time when a jurisdiction has changed the definition of time is in those files, along with a detailed history of why.

Example, California had an energy crisis soon after WWII, and changed when day light savings started/ended. There are time zone rules that track this history exactly, including a note about how clocks lost 6 minutes a day because PG&E changed AC from 60 to 59.5 Hz:

https://github.com/eggert/tz/blob/71faa2a55db2c9f21f4099b58c...

I am very surprised ICU can't handle it. ICU is the de facto standard of handling crazy localisation data
As far as I recall, Ireland is the only country to have its timezones setup that way.
I see 3 countries with negative DST in their RULE records:

* Eire after 1971: https://github.com/eggert/tz/blob/main/europe#L526

* Morocco after 2019: https://github.com/eggert/tz/blob/main/africa#L928

* Namibia between 1994 and 2017: https://github.com/eggert/tz/blob/main/africa#L1167

Plus Czechoslovakia 1946/47 and Chile since 2016, see https://en.wikipedia.org/wiki/Winter_time_%28clock_lag%29
If that resulted in a backwards time it wasn’t expecting ..,
Heh, database corruption expected in -1... -2... -3...
It should be easy enough to test -- set the system to Europe/London or Europe/Lisbon.