4 ms·
Living UTC would be awkward, however as someone who works with real world data sets, USE UTC FOR DATA! and also iso-8601 formatting. Everything else is a nightm
by Eddy_Viscosity2 1y ago
Living UTC would be awkward, however as someone who works with real world data sets, USE UTC FOR DATA! and also iso-8601 formatting. Everything else is a nightmare. Thank you for attending my ted talk.
- macintux 1y agoMy co-workers consistently stick with UTC, but they refuse to include the time zone in strings in their databases. Drives me crazy.
- yen223 1y agoThe TIMESTAMP WITH TIME ZONE data type doesn't include the time zone, which is hilarious to me.
- mjevans 1y agoSad for me... https://www.postgresql.org/docs/current/datatype-datetime.html https://www.postgresql.org/docs/current/datatype-datetime.ht... Moments that are fixed in time: store the event in UTC and record the rest in a string. A description of a moment should instead by stored in the application's normalized and preferred format, often a string.
- Kwpolska 1y agoMoments in the future are not fixed in time. Countries change their time zones, sometimes with little notice. In most cases, humans will keep the event at the same local time.
- mjevans 1y agoCorrect, what you state is implicit in my meaning of a moment, rather than a specification for a potential moment.
- wwweston 1y agoUTC for data is perfect for events that have occurred. It has corner cases for planned future timing that require further thought and probably storing wall time + locale.
- Eddy_Viscosity2 1y agoI can see that would be an issue. Fortunately I guess, I don't have to deal with future events (except in case where the date formatting is ambiguous and I guess wrong, resulting in events appearing to have occurred in the future).