UTC Is Enough for Everyone, Right?
So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the <i>future</i> 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).