Conversation

Notices

1. Embed this notice
   Simon Willison (simon@fedi.simonwillison.net)'s status on Friday, 06-Dec-2024 05:04:05 JST Simon Willison

   I wrote a thing about "Storing time for human events" - how if you're building an events website used by actual human beings the standard advice of "convert times to UTC and just store that" isn't actually the best approach
   https://simonwillison.net/2024/Nov/27/storing-times-for-human-events/

   • Embed this notice
     Simon Willison (simon@fedi.simonwillison.net)'s status on Friday, 06-Dec-2024 05:04:02 JST Simon Willison

     in reply to

     • Loren Kohnfelder
     • Demiurg

     @demiurg @lmk I'm 100% on "store timestamps of when stuff happened as UTC" - the one edge-case here is for events that haven't happened yet where human beings think about them in terms of local time

     dilbert 1 likes this.
   • Embed this notice
     Loren Kohnfelder (lmk@infosec.exchange)'s status on Friday, 06-Dec-2024 05:04:03 JST Loren Kohnfelder

     in reply to

     @simon What is the source of this "standard advice"? I ask because it seems misguided on the face of it (not that I don't believe you that it's out there). Is there a collection of such standard advice - if it's like this I'd like to debunk it, could make an interesting series or book.

   • Embed this notice
     Demiurg (demiurg@fosstodon.org)'s status on Friday, 06-Dec-2024 05:04:03 JST Demiurg

     in reply to

     • Loren Kohnfelder

     @lmk @simon As stated in the article it is mainly about database design. You want to have time stamps in your data that are consistent over the globe. That's why you use UTC or Unix time. There are pitfalls, but the article suggest another layer above the UTC normalized storage and only for 'human facing' times, especially regarding events. I think it is still a good idea (and advice) to normalize time stamps for technical purposes, like log entries. It seems you have another take on this?

   • Embed this notice
     deutrino (deutrino@mstdn.io)'s status on Friday, 06-Dec-2024 05:05:32 JST deutrino

     in reply to

     @simon great intro to a deep rabbit hole, reminds me of my last long-duration "real job" where we budgeted 2 months for "DST fixes" to the calendar and spent 13 months rewriting the core logic to store something we named "intent time"... this was for groupware which absolutely did have calendar events in weird locations with attendees from all over the world. pretty sure I ran the risk of getting fired on that one, but calendar bug calls to support were nearly eliminated.

     dilbert 1 likes this.