this post was submitted on 29 Jun 2024
905 points (94.9% liked)

Programmer Humor

32721 readers
694 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 16 points 5 months ago (3 children)

It’s only bad when used incorrectly. Just store time in UTC and convert it to timezone of your setting to present it. Most modern languages offer a library that makes it just one more line of code. Not only it’s then clear and unambiguous, it supports all timezones.

[–] [email protected] 6 points 5 months ago (1 children)

Doesn't always work, especially if you need to work with any sort of calendar or recurring schedule.

[–] [email protected] 3 points 5 months ago

Yeah, timestamps should always be stored in UTC, but actual planning of anything needs to be conscious of local time zones, including daylight savings. Coming up with a description of when a place is open in local time might be simple when described in local time but clunkier in UTC when accounting for daylight savings, local holidays, etc.

[–] [email protected] 5 points 5 months ago

bingo. Timezones became easier when I learned that all apps and databases should have all times be in UTC. Let the UI do it's thing and accept local time and convert it, and vis versa.

[–] [email protected] 4 points 5 months ago* (last edited 5 months ago)

+1 for this. This is kinda the same issue with encoding, just UTF-8 everything and move on.