4 ms·
> 1. If you're recording an event in the past, store it in UTC. That works a lot less well when your analytics don't easily show that "make my coffee" is usual
by HWR_14 5y ago
> 1. If you're recording an event in the past, store it in UTC.
That works a lot less well when your analytics don't easily show that "make my coffee" is usually run in the mornings, local time.
- coldtea 5y agoHe said "store". What you describe is "display". You convert for reporting and UI.
- HWR_14 5y agoThen you run into all the problems in the article. Out of date time zones because they changed. Bad initial conversions because of time zone mismatches. Etc.
- chrishas35 5y agoNot when it's an event in the past. When the event in the past you know which TZ rules to apply for conversion. The issues arise for the future because you don't know what change may occur.
- deleted 5y ago[deleted]
- brewmarche 5y agoI agree, storing with an offset is better here, e.g. prefer `2022-03-13T08:00-04:00` over `2022-03-13T12:00Z` when the regional time zone of the event location was UTC-4 when the event occurred. Why? As instants they are both equivalent, but one carries additional information, namely the time that was on the wall where and when the event happened. Fixed offsets will never change, so this really is a frozen snapshot