Yeah, this is exactly the difference between what I’d call “timestamps” (something that represents a particular instant in time), and what I’d call “datetimes”, things like “midnight on Jan 1, 2019”.
I worked at an insurance startup that stored coverage period start/ends as timestamps, which ended up being semantically wrong. The coverage ends at midnight of the next year, wherever _you_ (technically the provider, I think) are. So there is no one single instant in time when coverage ends; a timestamp is the wrong data type for representing this.
If you've worked on a distributed team that had members in the UK/EU and the USA then you've run into this before when scheduling meetings.
A 10am PDT America/Los_Angeles meeting is different from a 6pm BST Europe/London meeting which is different from a 5pm GMT meeting and those will jump around by an hour depending on time changes. If the bulk of your team is in Seattle then you probably want to pick the US timezone for the meeting and not GMT or London. If you have a manager in London, though, who sets up the meeting time in their local timezone then Seattle employees will notice tomorrow that the meeting is a hour later in Seattle than it normally is.
If everyone shitcanned clocks jumping around twice a year this craziness would end.
I think this is the inverse problem. In this case, timestamp is the appropriate data structure for the meeting and each person's client needs to convert it back to local time, accounting for things like daylight savings time and so on.
Recurring meetings cannot be expressed as timestamps (unless you want all the humans to hate you). The recurrence has to be expressed in terms of local time (and date/day of week) in some (ideally per-event) timezone.
It's fine as long as all the meetings are conventionally expressed in one time zone.
If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't!
Such a mess. But it doesn't happen frequently enough for it to be worthwhile fixing/regulating/whatever
> If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't!
But this is a problem in the real world, not a software problem. Choosing to use UTC when that's not how the business actually thinks about schedules will lead to you just doing your own DST math, which is harder than just storing the correct time zones from the get go.
Sure it is a real world problem.
And no, I wasn't advocating for UTC which would not work for half a year, instead of causing a few days of minor headaches.
It's caused by the fact that different branches of a large corp have genuine situations where some meetings are between local employees and other situations where you invite a mix of distributed people.
Thus there is no "natural default" as to which timezone is "correct".
For a repeating meeting I think the construct you want is actually a datetime, generally.
E.g., a weekly meeting is not a meeting that happens on one particular timestamp and then repeats every 24*7 hours. If you hit daylight savings time, you want a 9am meeting to still be on the "new" 9am, not shift to 10am or 8am.
Future times are tricky. Some weekly meetings are 24 hours * 7 days apart. Some are at the same time in (fixed) LocationA, 7 days later; some in (fixed) LocationB. Some in whatever location the organizer is (maybe a personal reminder rather than a meeting with others).
It would be a lot easier if locations changing offsets to other locations was a lot less frequent.
Every calendar app I know asks for a timezone when scheduling a meeting. So if you schedule it in Europe/London, it will move in UTC. If you schedule it in GMT+1 (which what Europe/London is in summer), it won't.
IIRC in Saudi Arabia the start and end of daylight savings is decided on each year, so not only do you need a historical record, but there's no way to future-proof it without integrating some external source of data, otherwise you'd need to manually add the dates for each year at some point.
We adopted a policy the a `date` type is always interpreted in the reader's local timezone, which is sort how humans think of it anyway; put differently, a `date` type is always relative to the person's watch that is reading said value.
I worked at an insurance startup that stored coverage period start/ends as timestamps, which ended up being semantically wrong. The coverage ends at midnight of the next year, wherever _you_ (technically the provider, I think) are. So there is no one single instant in time when coverage ends; a timestamp is the wrong data type for representing this.