←back to thread

Debian 13, Postgres, and the US/* time zones

(rachelbythebay.com)
283 points move-on-by | 1 comments | 12 Sep 25 02:33 UTC | HN request time: 0s | source
Show context
burnt-resistor ◴[12 Sep 25 09:01 UTC] No.45220171[source]▶
Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.
replies(5): >>45220222 #>>45220233 #>>45221046 #>>45221092 #>>45221989 #
macintux ◴[12 Sep 25 11:34 UTC] No.45221046[source]▶
I work with a development team who manages data integration and migration for massive datasets, and they have sensibly set a standard that every date/time value they store in their databases will be UTC.

But they explicitly or implicitly have also decided not to store the timezone in the strings, so every single value is technically ambiguous. Absolutely drives me crazy.

Update: since there have been questions, these are strings, not native datetime values.

replies(4): >>45221416 #>>45221558 #>>45228759 #>>45238155 #
1. oftenwrong ◴[14 Sep 25 07:22 UTC] No.45238155[source]▶
In many systems it is reasonable not to include a zone. Usually that goes hand-in-hand with the desire to use a more compact representation, such as storing a numerical timestamp with a customary interpretation (usually UTC or TAI). If you must store a string, you may as well include a zone. Using ambiguously-zoned timestamps is an invitation for bugs. I feel your pain.