Wtf? I just learned that there's a one-hour interval every year that simply cannot be represented when daylight savings time ends (in regions that respect it) when using RFC 5545 iCalendar / ISO 8601 format if you want to specify a time zone identifier. This is the format that Google Calendar and most calendar apps follow. The only way around the issue is to use numerical time zone offsets (which in itself can be error prone due to the need to understand daylight savings and does not conform to the iCalendar spec). I'm working on NIP-52 calendar events, debating between using Unix timestamps and following the iCalendar format for maximum interoperability. The fact that there's a meaningful interval of time that can't be represented in the latter format seals deal for me, unless I'm missing something. That's pretty messed up.

Replies (21)

Que grande Terry felicitaciones por el trabajo que estás haciendo y vas a hacer con el calendario 👌👏👏
I let multiple apps go to their grave with open time related bugs. DST related, will not fix. I believe that they should fix time not me fix my app. Coding was what first turned me against time changes and I will die on that hill.
I‘lol throw my hat in for the unix timestamps. Each client app should be able to localize on the fly, and then you don’t have to worry about data going stale when regions switch time zones.
TIL
Terry Yiu's avatar Terry Yiu
Wtf? I just learned that there's a one-hour interval every year that simply cannot be represented when daylight savings time ends (in regions that respect it) when using RFC 5545 iCalendar / ISO 8601 format if you want to specify a time zone identifier. This is the format that Google Calendar and most calendar apps follow. The only way around the issue is to use numerical time zone offsets (which in itself can be error prone due to the need to understand daylight savings and does not conform to the iCalendar spec). I'm working on NIP-52 calendar events, debating between using Unix timestamps and following the iCalendar format for maximum interoperability. The fact that there's a meaningful interval of time that can't be represented in the latter format seals deal for me, unless I'm missing something. That's pretty messed up.
View quoted note →
yeah i had fun with that one. i wrote a little tool that generates a complete timezones and offsets and start-end from a data source... let me see if i can dig it up to help https://github.com/mleku/timelanguage this already has mostly current data on it. you need to run the "generator.go" function in the "data" directory after deleting the two json files in there to make it regenerate. takes a minute or two for it to do it. the languages are also part of the locale data, and includes currencies and phone codes and iso country codes and all that. it actually generates a plain one with just the time zones data the offsets are in seconds, and the start/end for places with DST are unix timestamps of the current next start/end i hope it helps. you can use it as is but i recommend you write some script to make it regenerate it every 3 months or so because who knows what the fuck governments are gonna do in that time lol
i should probably make a little web service that maintains these updating every few months and hosting the output json files for people to use. if someone wants to zap me some i'll do it (and the app will be open source so you can run it yourself). hit me up
stick to unix timestamps, but make a converter i didn't know about that hour when things are broken. that's pretty pissweak. i remember what a big deal the computer clock apocalypse that happened, when was it, 1999? what was it called again? people should all be using unix timestamps in their applications by now. it's what scientists fucking use.
ah yes, Y2K bug. mostly affected windows based systems of course, because windows didn't adopt posix time until later.