Hacker News Reader

Comment by landryraccoon | Hacker News Reader

It’s not just a matter of trust. Locale specific datetimes in the future are simply not computable to a point on a number line in the general case. Some locales have date changes that must be determined by the local government every single year. Israel is an example of such a case.

View on HN

Unix timestamp (actual reference with easy math) + timezone give you absolute time to work with, such that you can work out the correct presentation for the timezone even if the timezone has undergone multiple revisions in the intervening years.

There's still a bunch of problems (timezone of event origin? Event reporting origin? Server? Client? Client + presentational overlay?) and confusing things to work through (including relativistic problems) but the consistency of the reference point is valuable. Nobody is going to confuse what timezone you are using as your point of reference when you use Unix epoch. Just use a 64-bit number to hold it.

The suggested approach simply doesn’t work, because human calendars simply don’t work that way.

If the state of Indiana decides this year to change when they set their clocks forward and back, and you stored your appointment datetime as a timestamp, when do you show up for an appointment? At the new 930 AM after statutory date adjustment, or the now incorrect time stamp in your database? Will the DMV respect your claim that you had an appointment at epoch timestamp 1726651800, or will they say sorry buddy the clock on the wall says 9:30 AM, you missed your window? Are your taxes next year due at 1713173400, or are they due at midnight April 15th?

This is NOT a UI issue. This is an issue where the timestamp you calculated in the past literally does not mean the same calendar date in the future as it does now.

And if your answer is to recalculate the timestamp based on locale changes, what was the point of storing the timestamp? (I hope you stored an audit trail of the locale as well as the timestamp, otherwise you can't even recompute the timestamp). The timestamp is never the ground truth, the human readable string is the ground truth.

The timestamp for a particular human date time is not generally a computable function, because human governments change how dates are reckoned frequently, and the human government, not your database are the ground truth.

Very good point, which is a reminder that you have different "types" of dates that you may want to store.

Went storing the time at which an event happened (e.g. for a system log) then a UTC or UNIX time works, and it will be transformed at display time depending on the user's timezone.

When storing a future time at which to do something, it should be stored with its target timezone so you can always make sure it happens at the right moment. For this iso datetime representation makes a lot of sense.

That is exactly was I was referring to with needing to know whether it was an origination stamp or what, ie the context of the stamp. That problem holds regardless of the format you store the stamp in, because even if there is a colloquial understanding of how to interpret a time change (1030 on Thursday is still 1030 on Thursday) it doesn't hold for every context (5 hrs from now is still 5 hours from now, except if when you said 5 hours from now you meant clock time)

> If the state of Indiana decides this year to change when they set their clocks forward and back

On the other hand, the state of Indiana could just as easily solve most of our time issues by passing a law declaring a day to be exactly 24 hours ;)

https://en.wikipedia.org/wiki/Indiana_Pi_Bill

Reply on news.ycombinator.com