this post was submitted on 03 Apr 2024
384 points (95.5% liked)
Programmer Humor
32410 readers
307 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Store times in UTC, convert in UI to locale's timezone with one of any of the millions of timezone libraries. If you're storing in local time, you're gonna have a bad time.
Timestamp in UTC
But for time of day, use local time and store separate column with the timezone name. Don't use timezone offsets since that doesn't work with DST. You're better off with something like
America/New_Yorkbecause God knows what 2030 will look like.And if timezone are abolished, or DST, that's even more reason to store the timezone name.
It depends. If something needs to happen in local time (like, always at the same time regardless of daylights savings for example) you should be storing times in local timezone
Store in UTC with the tz offset and if you're using a modern tz library, that should handle it for you.
tz offset is really not enough. You'd need to save the time zone id and/or offset, to have you library calculate deviations such as daylight savings.
Even that, that would break if the user moves and now what they setup is using their previous timezone.
Basically, I'm saying that storing the offset works most of the time, but not all of the time.