Hacker News Reader

Comment by gsich | Hacker News Reader

There is a solution for this, Unix timestamps.

Looks like someone didn't read the article :) If you normalize to UTC for some future date with a timezone in Lower Left Elbonia Standard Time (GMT+7:42), and the Elbonian Revolutionary Army successfully form an overnight junta, retroactively declaring the country's timezone to be Free Peoples' Elbonia Revolutionary Time (GMT-12:00), suddenly your DB rows make no sense whatsoever.

The absolute point in time relied on future knowledge that did not yet exist, that invalidated any previous estimate of when it would occur. An external timezone reference (the Olsen DB) must be continually updated and separately referenced

This is exactly wrong I think:

If the timezone changes under my feet the unix timestamp might suddenly not refer to my birtday anymore.

Watching people struggle with this is frustrating.

Also I currently work with frontend and while it is no surprise that JavaScript has messed this up badly [0] it surprised me when I realised that a certain large UI framework had a) messed it up b) didn't realize it and tried to close it down when people tried to help.

[0]: they copied Javas first broken Date handling and suddenly they were stuck with it IIRC.

Edit: heh, double-ninjaed

That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.

How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.

From the user's perspective it is the same appointment. They think they have an appointment at 3:00 PM on Thursday. If there's a timezone change, and you just stored an integer, then from the user's perspective the meeting changed from 3:00 PM to 2:00 PM.

Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.

Your integer is wrong because it was computed by translating from the current offset of the timezone. What we are saying is that the timezone definition might change in the future (ex. Government no longer honor DST). At that point when you translate back your timestamp into local time it no longer matches the original schedule that the user set.

But the integer stays the same. That's the main point here. Everything else is just converting it to local time. Sure timezones might change that.

Reply on news.ycombinator.com