I have a meeting every Tuesday at 10AM in New York.
How do you store that? Given that it's sometimes going to be 1500UTC, sometimes 1400UTC, and in the future it could even be something else, and the date when it changes from EST to EDT in New York Can and Has changed.
Well, since you specified a recurring meeting ... you have to "actualize" the meeting for some distance into the future. So, you'd create a whole bunch of meetings in that timezone, on that date, then convert it to UTC. Sure, some will be 15:00, some will be 14:00, but that doesn't matter if you stay in the NY timezone.
But if you fly out to Amsterdam, it's really important that the time can and does reflect your current timezone ... or you're going to open zoom at exactly the wrong time. Even more fun is that EU DST is a different date than US DST.
I've used a database layout that mirrored the data that can be in an ical file, which supports defining the recurrence without having to actual create each instance, and supports recurrences with no end date.
We went with something similar to that at one point. Our problem was we had only a few dozen ms to render thousands of recurring events. Most customers didn’t look more than a few weeks ahead (though we rendered them out decades). Using your approach would have taken too long to calculate intersections — it was our initial approach actually — but just making a simple query and rendering actual events was much faster.
Because you are creating times for events you don't know what the UTC will be. if you are lucky your guesses will be right.
If you created an event in 2004 for 10AM New York in 2008, you may well have created it for 1500 UTC based on predicted time in 2008. When the Energy Policy Act of 2005 passed that event would have had to change to 1400 UTC. As you didn't store the timezone you had no idea whether to change it or not.
Chances are your users just ignored the problem, blamed the government rather than your poor code, or you didn't exist then, and you as an american-centric company has no idea that unpredicted unscheduled DST time changes occur all the time.
> Because you are creating times for events you don't know what the UTC will be.
This is what settings are for. This was an enterprise application, so the timezone was set for the location of the venue, in the settings. We knew exactly what timezone to convert from/to.
> if you are lucky your guesses will be right.
This is software, there is never a reason to guess.
tzdata makes guesses (predictions) all the time -- every time in the future is a guess. There is no way to know that a government won't change DST dates, or even shift a country to a different timezone.
Look at the whole Lebanon mess from earlier this year:
If you had, at Mar 24 2023 10:00 UTC gone and created a meeting at 10AM Beirut on Mar 27th 2023 it would have been at 0800 UTC (based on the official Lebanon position that DST would not start until April 21st [0]), and you would have been wrong [1]
Had you stored the datetime with location then you would have been fine.
The tzdata community far know more about time than you do and make a good job at guessing what the time will be, but they still have to issue multiple updates each year due to changes from different governments.
Take this update from 2021 when Fiji suspended DST for the following year
It's a guess. nobody in October 2021 could say for certain that Fiji would or would not have DST in 2023.
This isn't controversial. Past dates can be problematic - especially from 50+ years ago (historical data may crop up which shows that a specific location had different UTC offset which means a historical update is needed), but for future dates all predictions of UTC offsets for geographic locations are a guess [2]. Hell you can't even store the tzdata location group (say Europe/London) because in the future Scotland could decide to keep DST but England/Wales/NI/Ireland could move to BST year round. In that situation meeting at 10AM Edinburgh stored as 10AM Europe/London would be at the wrong time. That's more rare than DST date shifts, but it still happens
What happens when New York stops following DST? Half of your precalculated events are now wrong. You could recalculate them but now you have to have logic for figuring out when to do that.
Much better solution is to store the repeating event, and each event time, in the originating time zone. Then calculate other time zones from that, which is a little more complicated but doable.
That’s a business problem no? Because any events with attendees in other timezones are going to be different now too. So it boils down to customer communication and business decisions. Both are valid.
The business decision is that the event occurs at 10 AM local time in New York on April 29th 2026, not that it occurs at XX:00 GMT.
There is no way to know whether New York will be in DST or not then. Timezone changes can be made with just a couple of days notice, and sometimes not even clear even once they've happened (or not happened)
Yeah, that might be your business's decision, but every business will make different decisions. No matter what, if a timezone changes like that, you've got issues since you need to update the TZ database in the servers.
- you can shift the time to the new timezone if it is stored in UTC (this is effectively the same as storing them in local time). You still have impacted users to email.
- you can leave it unshifted. You still have impacted users to email.
No matter what, you have to communicate with users. The difference comes down to how much work you want to do and how much coordination you have.
> - you can shift the time to the new timezone if it is stored in UTC (this is effectively the same as storing them in local time).
No you can't, as you don't know if the time was New York, or London, or Morocco
> You still have impacted users to email.
Why, nothing has changed.
Your decision to ignore the users wants (I want an event as 10AM in new york) and replace it with your wants (I want to store time in UTC for some reason). That's wrong.
> No you can't, as you don't know if the time was New York, or London, or Morocco
Hmm. I'm not sure what you mean? Users in these kinds of applications specify their timezone somewhere. It usually isn't enough to rely on browsers for this kind of setting. For example, when you travel to a different timezone in Google Calendar, it warns you that your setting doesn't match your current timezone of your calendar, but the timezone setting is independent of your browser.
> Why, nothing has changed.
I don't think you're thinking of the knock-on effects of a random political change to a timezone in a calendar-ish application. If NY were to suddenly disable DST -- and for illustration purposes, let us assume they disable it DURING DST -- even if you store it in the (self-proclaimed) "correct" local time, people who are attending one of your events from a different timezone will observe your event shifting by an hour. Any event from someone else's calendar in another timezone will likewise be observed as shifting one hour. Thus, as a business, you must communicate to these affected users that they need to be aware, after all, someone a world away from the NY timezone is unlikely to be aware of the political ongoings of NY.
But this is an extreme case, right? Surely we'll get some kind of heads-up? It doesn't change the effect, it just delays it. Even if we store them in UTC, we can simulate the same effect by manually shifting people's calendars in that timezone with a single query.
> Your decision to ignore the users wants (I want an event as 10AM in new york) and replace it with your wants (I want to store time in UTC for some reason). That's wrong.
That's your opinion and ignores a whole host of potential other reasons to store it in UTC vs. local time, and none of it has anything to do with users, but business requirements in order to perform something more powerful and valuable than storing time.
If your alarm is set to go off at 7AM London time on Dec 1st, and the UK government decides to shift the UK to UTC+5 for some reason, the alarm still needs to go off at 7AM London time, but it's changed from 0700UTC to 0200UTC.
There is no need to inform the user of a change if you have stored the date correctly -- as 7AM London time.
If you had stored the alarm at 0700UTC, you are wrong. You may be lucky and the government doesn't change the time, but just because you are lucky it doesn't mean you are right.
If your user wants to store a date in UTC, that's fine, that's their choice. If they want to store it as London time, that's also fine.
None of this matters if it only affects a single person/organization. It doesn't matter what time zone you are in, it will "just work," the only thing that is different is the amount of effort required by the dev. Even then, there's probably going to be a delay while tzdata is updated downstream and on the servers/phones/etc.
It only matters when you have people in multiple timezones. A better analogy would be if you set an alarm to go off 7AM London time, for me, and I am in Amsterdam time.
When the UK decides to switch to UTC+5, that 8 AM alarm (CEST) won't go off ... instead it will go off at 13:00 CEST. That is why you need to notify users that have an appointment in a different, affected, timezone.
How do you store that? Given that it's sometimes going to be 1500UTC, sometimes 1400UTC, and in the future it could even be something else, and the date when it changes from EST to EDT in New York Can and Has changed.