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 simonwillison.net/2024/Nov/27/... - ThreadSky

simonwillison.net • 89 days ago

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/

Comments

i-am-j.ag•86 days ago

Another pitfall example for why storing user intent is best: recurring events. In October I say that I want a weekly event in Asheville at 12pm. If I store that intent in UTC, come November, it will start recurring at 11am local time.

merehnau.bsky.social•89 days ago

This makes a lot of sense - you’re prioritizing the design according to the primary users of the system - humans who live in relativistic time zones.

The “exact instant when this occurs relative to other events” is a secondary concern and can be derived as UTC when necessary.

cackhanded.net•89 days ago

Reminds me of handling dates at Artfinder, where some artworks had timestamps accurate to the month and some only to the century or even dynasty.

simonwillison.net•89 days ago

I've tried handling fuzzy dates before but never at the dynasty level!

cackhanded.net•89 days ago

It was the worst python I ever wrote (it was the first python I ever wrote).

neomanic.bsky.social•88 days ago

this is the reason for ISO 8601-2:2019, which adds extensions to deal with (copied)
• uncertain or approximate dates, or dates with portions unspecified;
• extended time intervals;
• divisions of a year;
• sets and choices of calendar dates;
• grouped time scale units;

1/2

neomanic.bsky.social•88 days ago

• repeat rules for recurring time intervals; and
• date and time arithmetic.

I have a personal project that would really benefit from an implementation... although I'm sure I'll go absolutely insane.

2/2

timfish.dev•89 days ago

Last time I did this I settled on storing UTC + time zone. The app had to be tested across a DST change before I was convinced it would all work 😂

simonwillison.net•89 days ago

That's good enough provided you can trust your users to enter the correct timezone!

timfish.dev•89 days ago

This was for time series capture. We just used the local machine timezone. Display options were capture TZ, current TZ (if it differed) and UTC.

The main concern was having graphing working across DST changes so we graphed in UTC and created graph ticks based on display time.

timfish.dev•89 days ago

ie. You can't graph time series data in a timezone with DST changes 😆

davebauerart.bsky.social•86 days ago

Oh, I remember learning time math to solve an across DST bug back in the olden days. Brain bending.

whyfly.bsky.social•89 days ago

Heh. I am working through all this *yet again* right now and you're hitting all the beats that I've been trying to carefully reckon with. Thank you!

barneylaurance.uk•86 days ago

Agreed. Jon Skeet wrote something similar in 2019 https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/

chreke.com•89 days ago

Just use .beats

kensey.bsky.social•89 days ago

I think you can still cover all the cases you mentioned by storing just UTC and using basic validation plus other data that is generally already stored:

kensey.bsky.social•89 days ago

1) User entered the wrong time zone: Nothing will fix this after the fact except the creator themselves, but you can check consistency as they enter info. If they enter a timezone that doesn't match the location, you can warn them about the mismatch (and you can pre-fill the timezone).

kensey.bsky.social•89 days ago

If they later update the event with a different time zone (or a new time across a DST change), you can ask them if the entered time should stay the same ("it's still happening at 6:00 PM in the new local time") or change.

kensey.bsky.social•89 days ago

2) User entered the wrong location and corrected it later: if the new location is in a different time zone or observes different DST rules that affect that event, you can prompt as with the prior case.

kensey.bsky.social•89 days ago

3) DST rules or zone offset changed between creating the event and its occurrence: If the creator never comes back to edit or confirm the event, I don't think you can say for sure when the intended occurrence of the event is. The event creator and/or host should be asked what they want.

kensey.bsky.social•89 days ago

In the meantime, if the event creation time (which you should usually have a timestamp for) is prior to the rule change, you can display a warning to viewers/attendees about the change and that they should confirm with the host whether the original time is still the correct one.

jperras.com•88 days ago

My all-time favourite bug: some of our users would create events on their phone, but couldn't find them afterwards.

Those users (in SE Asia) had their phones set to use the Buddhist calendar; we were using the "local" calendar API in iOS. Events were created just fine, but 543 years in the future!

bsattva.bsky.social•88 days ago

This is fantastic!!!

aeracode.org•89 days ago

Do you remember what the case was where we had an event venue that moved through timezones - I think it was a cruise ship?

mrswats.jovell.dev•89 days ago

Oh God, that sounds awful

vishal-learner.bsky.social•89 days ago

Thanks for writing this! I've always just assumed UTC was a silver bullet (as much as a silver bullet as date/time can get) but your solution makes a lot of sense. One thought as I was reading your solution: what would the UI/UX look like for remote events? I asked Claude to come up with a solution.

simonwillison.net•86 days ago

Here is a fun piece of computing history: in 2007 the Bush administration changed when DST started, and because Exchange stored event times converted to UTC Microsoft had to release an "Exchange Calendar Update Tool" to help try and fix everyone's calendars https://web.archive.org/web/20070302224145/http://support.microsoft.com/kb/930879

mborus.bsky.social•86 days ago

This is even more true in situations where the „event“ is a moving target, like a vessel traveling between countries. And when one of those is Morocco, where the king can decide to change summer time rules on short notice. It really helps to store the original local times…

blu3r4d0n.shutdown.network•86 days ago

didn't realize that presidential administrations could change this

simonwillison.net•86 days ago

It was an act passed by congress in 2005

blu3r4d0n.shutdown.network•86 days ago

ah okay! that makes more sense

burntsushi.net•89 days ago

I don't think you mentioned this, but one more thing to be careful of *if* you're storing events in the future: the time zone rules for the user's locale may change (e.g., DST might be abolished).

burntsushi.net•89 days ago

You can mitigate this by not only storing the local time and time zone, but also the UTC offset of the future time using the present rules. Then when you go to use it, you can detect if the rules changed the offset in the interim and decide how to handle the conflict.

burntsushi.net•89 days ago

Jiff (inspired by Temporal, which has the same functionality) will handle this for you automatically: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html

So all you need to do is serialize your time and all relevant bits are captured automatically via RFC 9557. As long as you're using Jiff's Zoned type, you can't mess up!

simonwillison.net•89 days ago

I wrote about that when you first released it! https://simonwillison.net/2024/Jul/22/jiff/

rod.begbie.com•86 days ago

Yup, we learned a lot of this when building Sōsh back in the day. The task of figuring out what activities to show to users involved almost no time-zone calculations because we were recommending to a user physically in the same timezone as the venue/event.

davebauerart.bsky.social•86 days ago

I was going to argue but I think you come up with a pretty good solution, at a minimum the UI needs to consider what the user wants/needs.

charlieg.bsky.social•86 days ago

Definitely challenging. But storing based on old time zone is not sufficient. If the person changes time zones when traveling you want the app to show their new timezone. Likewise you probably want to keep the old timezone for engagement metrics of events.

simonwillison.net•86 days ago

I'm mainly talking about storing the time of a physical future event occurring in a location here - so the case of users traveling isn't as relevant

charlieg.bsky.social•86 days ago

Ah gotcha. Storing timezone and utc makes sense there as long as you change it with a venue change 😅

I was thinking more broadly of how to store future and past date times as I recently had to make this decision on multiple occasions and it gets annoying.

tdietterich.bsky.social•89 days ago

Nice observations. I schedule a lot of international zoom meetings with regular recurrences. I'd love a UI that shows me the consequences of my scheduling choices (e.g., which attendees will be inconvenienced by DST changes)

tdietterich.bsky.social•89 days ago

Some of my attendees are in a region without DST. We decided to make their location the "place", so that the meeting time would never change for them. People living in DST locations are expecting a change, whereas the others were being caught by surprise.

adamel.dev•86 days ago

📌

gterrill.bsky.social•88 days ago

I wrote a booking app for Shopify. How hard could it be I thought :-) 10K+ merchants across multiple tz's. All sorts of corner cases especially when dealing TZ changes and future recurrences. Definitely agree with the idea of keeping local time as well as UTC - its the only way to deal with it.

mattstubbs.net•89 days ago

Here's an example of a much better timezone picker from the Fastmail calendar: the timezone abbreviation is easily identified, and you can search by city or timezone.

barneylaurance.uk•86 days ago

I don't really like the GMT abbreviation for London, since that's only applicable in winter. But I don't know what else to suggest, I don't know know any abbreviation for the UK timezone throughout the year.

mattstubbs.net•75 days ago

I believe all the cities listed in that screenshot would be similar: Los Angeles is PDT in the summer, while Sydney is AEST in the winter. In June I think you'd see BST for London.

bence.dev•88 days ago

what's floating time 😳

simonwillison.net•89 days ago

Yes! So much better than Google Calendar

Comments

Posting Rules

Reply