this post was submitted on 01 May 2025
1077 points (97.0% liked)

Comic Strips

16329 readers
1751 users here now

Comic Strips is a community for those who love comic stories.

The rules are simple:

Web of links

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] arc@lemm.ee 30 points 1 day ago (5 children)

The sane way of dealing with it is to use UTC everywhere internally and push local time and local formatting up to the user facing bits. And if you move time around as a string (e.g. JSON) then use ISO 8601 since most languages have time / cron APIs that can process it. Often doesn't happen that way though...

[–] expr@programming.dev 7 points 1 day ago

Generally yes, that's the way to do it, but there are plenty of times where you need to recreate the time zone something was created for, which means additionally storing the time zone information.

[–] nBodyProblem@lemmy.world 1 points 1 day ago (1 children)

The BEST way is to use the number of seconds after the J2000 epoch (The Gregorian date January 1, 2000, at 12:00 Terrestrial Time)

[–] arc@lemm.ee 1 points 11 hours ago

ISO 8601 goes from 1582 (Julian calendar adoption) but can go even further with agreement about intention and goes down beyond the millisecond. Not sure why I want an integer from the year 2000 which only represents seconds.

[–] hazypenguin@feddit.nl 4 points 1 day ago

Definitely. If your servers aren't using UTC, then when you're trying to sync data between different timezones, you're making it harder for yourself.

[–] Hexarei@programming.dev 3 points 1 day ago

This is what I try to do in the few apps I've written that had to deal with dates and times