7 ms·

> 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 h

by dqv 3mo 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 3mo ago
These 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.
- dqv 3mo ago
  "overengineering" UPDATE appointments SET starts_at_utc = local_time AT TIME ZONE timezone_name WHERE timezone_name = 'America/Vancouver' AND starts_at_utc > now();
  - pphysch 3mo ago
    You elided the part where you are adding an extra column to your database just for this rare corner case.