this post was submitted on 08 Jul 2024
697 points (98.5% liked)

Programmer Humor

19453 readers
69 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 

Template

Further reading: RFC 3339 / ISO 8601

you are viewing a single comment's thread
view the rest of the comments
[โ€“] GTG3000 20 points 3 months ago (2 children)

Anything an API returns should just look like 1720533944.963659 .

There's no reason to store dates as anything other than UTC. User-side, sure, timezones are useful. Server doesn't have to know.

[โ€“] [email protected] 17 points 3 months ago* (last edited 3 months ago)

This is absolutely fundamentally wrong. What you've described is what Nodatime calls an Instant, and it's a very important data class, but there are valid reasons to use other classes.

A LocalDateTime cares about the date and time locally. An event scheduled for 8am every Monday might use this. It would update accordingly if you move locations to a new locale.

A ZonedDateTime can almost be directly translated into an Instant, except that one time zone might change. If you go into or out of daylight saving time, or your region decides to change its time offset. Oslo time is still Oslo time. You use this if your event occurs at a specific time in a specific location.

An OffsetDateTime is like a ZonedDateTime, but instead of being tied to a specific time zone (e.g. "Oslo time") it's tied to a specific UTC offset (e.g. UTC+1).

You don't have to use Nodatime, but you should at least think deeply about what your time objects actually represent and what is the best way to represent them.

See the creator of Nodatime's presentation about thinking deeply about time for more.