←back to thread

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

(rachelbythebay.com)
283 points move-on-by | 4 comments | 12 Sep 25 02:33 UTC | HN request time: 0s | source
Show context
reactordev ◴[12 Sep 25 12:23 UTC] No.45221373[source]▶
Ooofff. The two difficult things in software engineering, naming, and timestamps.

This hit me in the early 2000s and now everything I do is in UTC. All dates, timestamps, everything, UTC. If you want to look at a local window in time, convert the window to a utc start and end date and search. When viewing, use a js function to translate the utc date to a local one to print. The mental gymnasium of local to utc to local again…

replies(2): >>45221583 #>>45222947 #
1. umanwizard ◴[12 Sep 25 15:08 UTC] No.45222947[source]▶
Some times cannot be expressed in UTC.

For example: “this meeting will take place at 10 AM on July 31st, 2026, US Pacific time” cannot be expressed in UTC. You can guess what time UTC that refers to, and you’ll probably be right, but you’ll be wrong if it turns out for example that the US abolishes DST before that date.

replies(1): >>45223791 #
2. zajio1am ◴[12 Sep 25 16:21 UTC] No.45223791[source]▶
In that case it is no really a time, it is a condition.
replies(2): >>45224472 #>>45225993 #
3. bmacho ◴[12 Sep 25 17:27 UTC] No.45224472[source]▶
Yup, it's a function that leads to a time, depending on some things. And you can't express it in UTC, so you better store the whole function (as a string, for example). QED
4. layer8 ◴[12 Sep 25 19:50 UTC] No.45225993[source]▶
If the “condition” is what’s important for whatever you want to achieve, then that’s the thing to store.

Moreover, most people in real life will understand that to be a time and won’t care how it maps to UTC.