I wonder what really bad real-world problems this has caused? Personally I’d never schedule something for 3am but surely some flights must be scheduled for that time etc.
quoting note1p3e…x85aWtf? 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.
https://github.com/nostr-protocol/nips/pull/597#issuecomment-1633433118