←back to thread

How to Think About Time in Programming

(shanrauf.com)
189 points rmason | 4 comments | 24 Jun 25 20:01 UTC | HN request time: 0s | source
Show context
mzl ◴[25 Jun 25 07:49 UTC] No.44374665[source]▶
As many others have said, time and calendars is messy, and there is often no correct solution but just a bunch of trade-offs. Jon Skeets Storing UTC is not a Silver Bullet (https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...) was very influential for me in realizing some of the subtleties in what a point in time means for a user, and how that should incluece the design of a system.
replies(1): >>44377010 #
sfn42 ◴[25 Jun 25 13:19 UTC] No.44377010[source]▶
I have never worked on a system where simply storing everything as UTC isn't a perfect solution.

I know they exist, but I would say those are niche. And even for applications where you can't just use UTC for everything and be done with it, the vast majority of timestamps will be UTC. You'll have one or a few special cases where you need to do more fancy stuff, and for everything else you just use utc.

replies(1): >>44378131 #
1. RitzyMage ◴[25 Jun 25 15:00 UTC] No.44378131[source]▶
> I have never worked on a system where simply storing everything as UTC isn't a perfect solution.

> I know they exist, but I would say those are niche.

I firmly disagree with this, but I think that is because I think timestamps are very different than dates. Two examples my team runs into frequently that I think are very common:

1. Storing the time of an event at a physical location. These are not timestamps and I would never want to convert them to a different time zone. We had google calendar trying to be smart and convert it to user's local time because it was stored as a timestamp, but it is not a timestamp. I don't care where the user lives, they will need to show up Jan 2nd at 3pm. Period. I hate when tools try to auto-convert time zones 2. Storing "pure dates" (e.g. birthdays). The database we use does not allow this and we have to store birthdates in UTC. This is an abomination. I've seen so many bugs where our date libraries "helpfully" convert the time zone of bitthdays and put them a day before they actually are.

Storing UTC may solve almost all timestamp problems, but timestamp problems are a pretty narrow slice of date and time related bugs.

replies(1): >>44379279 #
2. sfn42 ◴[25 Jun 25 16:42 UTC] No.44379279[source]▶
You're completely right, for these niche cases it matters. I'm not saying you should indiscriminately apply UTC to every problem, I'm just saying usually datetimes should be stored as UTC.

And the reason I feel the need to say this is that most systems I've worked on don't do that. They use local time for things that have no business being local time.

UTC should be the default solution, and local datetime usage should be a solution in the few situations where its needed.

And yeah, dateonly is nice. If the db doesn't support it you can just store it as a string and serialize/deserialize it to a DateOnly type in your software.

replies(1): >>44384986 #
3. mzl ◴[26 Jun 25 07:14 UTC] No.44384986[source]▶
I'd say, in general any time a time-value somehow originates as a part of an interaction with a human, that time-value carries with it the context of a timezone and the expectations of what that timezone means for that human.

For internal timestamps such as ordering events in a database, them UTC or something similar is nice. Bet the point then is that those values are not really meaningful or important in the analog world.

replies(1): >>44390211 #
4. sfn42 ◴[26 Jun 25 18:52 UTC] No.44390211{3}[source]▶
Pretty much everything most user-facing apps do generates time values. Maybe it's more accurate to say any time a user actually inputs a date and time. Stuff like scheduling and booking software definitely needs to consider these things.

Basically if you want to preserve the original input then obviously you won't change it. If you just want to record an instant in time you use UTC.