Storing UTC for future times has never made much sense. But people still think UTC is the silver bullet for storing timestamps, ie. for records of past events.

Storing UTC for future times has never made much sense. But people still think UTC is the silver bullet for storing timestamps, ie. for records of past events. But even this is prone to failure. At some point someone will ask the question "how many events happened before lunch time?" This is a very clear and reasonable question to ask, but when is lunch time? Unfortunately many implementations simply store the UTC timestamp and throw away any time zone information (e.g. postgres TIMESTAMP WITH TIME ZONE, despite the misleading name). There are two ways around it: store the user's current time zone in another field, or record it in something like ISO8601 as local time with offset (although this only records the offset, not the IANA time zone). Both options have pros and cons. I wish implementations supported the basic tuple of (timestamp, timezone) where timestamp is a Unix-style timestamp (a number). The timezone can be ignored when it isn't needed, but is always there when it is. The difficulty is how to store the timezone and I'm sure there are numerous other issues with this.