Storing UTC is not a silver bullet

This is the same as the alarm clock problem. When a user creates an event, what does that user _mean_? In the alarm clock example, what should happen if I've set my alarm clock 7am and then travel to a different time zone? In the conference event example, what should happen if the local time zone rules change, or daylight savings time comes into force? Did the event organiser print marketing materials that said "starts at 1000 UTC" or "starts…

I think summary here is that if you are storing an exact moment in time then UTC does the job. If however you are storing a future date and time in a certain location, due to the uncertainty about future daylight saving time changes you have to save it with time zone information in order to adjust for future changes to that system. I suppose it’s the difference between exact time and social/political time (there is probably a better term…

This article always bugged me, because it needlessly makes things seem complicated. There are times when you are trying to represent a moment in time, and then there are times when you are trying to represent a moment in a calendar (which is not the same as a moment in time). It's all about capturing intent and using the right tool for the job. The moment in time case is pretty straightforward. The moment in a calendar case can get…