Post

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.

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

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 😂

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

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.

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:

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).

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.

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

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 web.archive.org/web/20070302...

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).

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.

Jiff (inspired by Temporal, which has the same functionality) will handle this for you automatically: docs.rs/jiff/latest/... 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!

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.

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

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)

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.

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.