I was asked recently: “I handle events in precise locations and always display event dates with the event place timezone, why would I save those dates as UTC rather than the fixed offset?”

An interesting case, if you’re sure, those events cannot change at all (meteor fall on a particular city), yes you can save the date with some +04:00 timezone offset, no matter if the city timezone will change meanwhile, the meteor fall won’t take the timezone changes, country/city date changes into account to slow down or speed up, but in most case you more likely will have events such as a concert in a particular city. This more common case implies that things can still change, you can change the date without changing the city, or even change the city without the date. Then if you save the city location, you can easily retrieve the timezone from it. So you would have a not needed duplicate data if you would save date with timezone and the city. So the UTC is still a good choice, save your date-time without timezone (implicitly UTC), save the city. So if you save date = “2019–06–24 01:00:00” and city = “Ottawa” in your DB, you can easily find the timezone of Ottawa “America/Toronto” then display the date using this timezone to display: “2019–06–23 21:00:00, Ottawa local time”

You would also be nearly certain of the immutability of your event if they are in the past (nearly because you still can save mistakes you want to fix later), but still, you may need to sort them by date, the faster way to do it is to sort them raw (in the SQL query if it’s a SQL DataBase for example) and in this case, you need to have all your dates in the same timezone if you want the sorting to be correct.

So even in this case, UTC is still the right timezone to use.