Comment by 0x0

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a UTC timestamp today, and the timezone rules are updated between now and then, your UTC timestamp may end up being incorrect. I guess you could have an additional "precalculated-utc-timestamp" column but regularly re-calculate this from the "yyyy-mm-dd hh:mm:ss + timezoneID" (especially when you upgrade your Olson tzdata).