Hacker News Reader

Comment by q7xvh97o2pDhNrh | Hacker News Reader

Dates should be integer seconds since epoch. Timezones are essentially a UI concept.

The date value should always be stored and passed around as an int — and then only transformed into a user-readable string on the client-side at render-time, only when it's necessary for a human to read it. It's the job of frontend code to take in the date as input (still as an int), detect the reader's timezone, and render accordingly.

For some systems, you may want more precision, in which case millis (or nanos) are reasonable, as long as you choose a big enough int type to hold them.

Once humanity goes from 1 planets to N planets, the whole thing will become a mess again thanks to relativity, and software engineers of the future will have to deal with figuring out how to convert an Earth timestamp to a Martian timestamp — and what it even means for two timestamps to be "equal" then.

But that's next century's problem. ;)

View on HN

When you store the time of a future event (like a reminder for 1 year from now), and integer since epoch does not work.

Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen. However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.

Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.

> However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.

This is a really interesting scenario that I hadn't considered at all. You're totally right; this approach breaks down there.

Off the top of my head, it looks like this scenario would require manual action either way, though. Either it's an update of the packaged datetime library to incorporate this new regulation, or it's a database migration to update the timestamps for affected users.

The same goes for "times this business is open" to store "9am-4pm on weekdays" you probably want to store almost exactly that string, rather than some ints. Generally speaking, dates stored as "ints" are mostly good for timestamps of events that have already happened (or even more precisely events that your application generated/logged live). Other use cases may be more rooted in the "human" dates than in absolute time

> Timezones are essentially a UI concept.

Sometimes they are, sometimes they are not.

For example...date+time of birth. The legal date (timezone) is a significant part of this event's time.

> passed around as an int

We're talking about a CSV. CSV don't have ints.

You can use base-10 encoding of the Unix timestamp, or the ISO 8601.

Yes to ALL of that.

I would add that a UI might prompt for a date as well, which of course would be entered using a local time input element based on the the users time zone. But that local time would immediately be converted to an int and passed to an API.

Not sure what you mean by passing the timezone as int.

Edited a few words and punctuation marks to make my intent clearer; hope that helps. The idea is to deal with the timezone at render-time, not to pass it around.

Reply on news.ycombinator.com