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
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.
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.
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.
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.
