undefined | Better HN

0 pointsmasklinn9y ago0 comments

> You want a meeting at 1100 local time.

On a specific day.

> The calendar doesn't change.

Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time).

> This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

* while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local

* this is stored as 2012-01-05T22:00:00+0000

* tzinfo gets updated with Pacific/Apia at UTC+13

* your calendar now tells you your meeting is on January 6th at 11 local

* you're a day late

0 comments

1 comments · 1 top-level

mjevans9y ago

You're both correct.

The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick.

P) The event is at a precise internationally recognized moment (better for co-ordination globally).

R) The event is in local time (like a lunch date) and expected to remain colloquially fixed.

In the case of the first you store a precise UTC timestamp and drop the timezone (it's UTC).

In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.

j / k navigate · click thread line to collapse