this post was submitted on 01 May 2025
1073 points (96.9% liked)
Comic Strips
16378 readers
1461 users here now
Comic Strips is a community for those who love comic stories.
The rules are simple:
- The post can be a single image, an image gallery, or a link to a specific comic hosted on another site (the author's website, for instance).
- The comic must be a complete story.
- If it is an external link, it must be to a specific story, not to the root of the site.
- You may post comics from others or your own.
- If you are posting a comic of your own, a maximum of one per week is allowed (I know, your comics are great, but this rule helps avoid spam).
- The comic can be in any language, but if it's not in English, OP must include an English translation in the post's 'body' field (note: you don't need to select a specific language when posting a comic).
- Politeness.
- Adult content is not allowed. This community aims to be fun for people of all ages.
Web of links
- !linuxmemes@lemmy.world: "I use Arch btw"
- !memes@lemmy.world: memes (you don't say!)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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...
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.
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.
This is what I try to do in the few apps I've written that had to deal with dates and times
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)
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.
Simplicity and precision.
Who said it was only measured as an integer? Seconds are a decimal value and many timekeeping applications require higher precision than to the millisecond. Referencing an epoch closer to our current time allows greater precision with a single double-precision floating point number.
Want to reference something before J2000? Use a negative number.
It’s independent of earth rotation, so no need to consider leap second updates either unless you are converting to UTC. It’s an absolute measure of time elapsed.
I think you skipped part of the sentence.
The clue was in "user facing bits". UTC represents time as an absolute. If you want to show local time, or deal with daylight savings you run UTC through a function on its way to the user.