>For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones.Saving as UTC doesn't really solve the issue (although it seems like it does).
The issue that the previous posters (Khao, laut) didn't make explicit is that we have 2 concepts of datetimes:
1) scientific datetime (which UTC is unambiguous, except for obscure things such as leap seconds)
2) socially-constructed datetime (which "local" time + TZ resolves most (but not all) of the ambiguities)
Scientific(UTC) datetime works great for past events like server logs, and some types of future events such as celestial events. For example, the upcoming solar eclipse in August 21 2017. Regardless of what future DST rules are decreed by the government, the moon is going to move in front of the sun at a 16:48:33 UTC time.
Socially-constructed future datetime such as appointments don't work the same way. For example, we presume that a Super Bowl on the east coast in the year 2025 will have a kick off of 6:30pm but we can't encode that as UTC unambigously because we don't know today what DST rules will be in effect 10 years from now. In 2016, we don't know whether to encode it as 22:30UTC or 23:30UTC.
That said, if the planning horizon is short (such as sending out alerts for an upcoming conference call to participants spanning timezones), one can encode it as UTC internally and then decode it to local wall-clock time. It may be simpler that way with less bugs.