pphysch on British Columbia, Time Zones, and Postgres

Comment on British Columbia, Time Zones, and Postgres

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 2mo

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/...

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 2mo

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 2mo

"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 2mo

You elided the part where you are adding an extra column to your database just for this rare corner case.

Comments