3 ms·
This is one of those cases where I would prefer to be antifragile and rapidly "patch the data" once as opposed to trying to perfectly solve problems like this b
by pphysch 4mo ago
This is one of those cases where I would prefer to be antifragile and rapidly "patch the data" once as opposed to trying to perfectly solve problems like this before they arise. In all likelihood this will never happen in a particular timezone.
- dqv 4mo ago> In all likelihood this will never happen in a particular timezone. You sure about that? https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/... 2026b - changes to future timestamps 2026a - changes to past and future timestamps 2025c - changes to past timestamps 2025b - changes to past timestamps 2025a - changes to future timestamps 2024b - changes to past timestamps 2024a - changes to future timestamps 2023d - changes to past and future timestamps 2023c - changes that changed future timestamps reverted 2023b - changes to future timestamps I definitely prefer the... fragile? approach for this problem
- pphysch 4mo agoThese aren't global timezone changes, these are changes to individual or small batches of timezones. If you are not scheduling future events in these timezones, they do not affect you. You are welcome to overengineer systems to possibly prevent potential future timezone-shift-caused data corruption. Unless I ran a globally distributed appointment/event database, I would personally avoid doing that.