6 ms·
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
by ta1243 3y ago
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.
- withinboredom 3y agoWell, 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.
- ianburrell 3y agoWhat 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.
- withinboredom 3y agoThat’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.
- ta1243 3y agoThe 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) See https://mm.icann.org/pipermail/tz/2023-March/032761.html https://mm.icann.org/pipermail/tz/2023-March/032761.html for example. Therefore the date stored should be April 29th 2026 10AM in New York, not 1400 UTC or 1500 UTC
- withinboredom 3y agoYeah, 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.
- ta1243 3y ago> - 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.
- withinboredom 3y ago> 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.
- jayknight 3y agoI'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.
- withinboredom 3y agoWe 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. Optimization is the ruination of all elegance.
- ta1243 3y agoIf you have created those decades ahead against UTC they will mostly likely be wrong unless the business wanted them recorded as UTC.
- withinboredom 3y agoWe didn't have any issues at all, worked for over a decade and it was super fast. I'm curious how you'd think they would be wrong?
- ta1243 3y agoBecause 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.
- averageRoyalty 3y ago> Even more fun is that EU DST is a different date than US DST. And Australian DST is on different dates (it's summere here now), and not every state always changes on the same date.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- wiredfool 3y agoI have meetings in us-eastern, Irish time, and Indonesian/se Asia time, scheduled on the same calendar, and somewhat intertwined. 2 do DST. And they change on different weeks. One is a half hour time zone and doesn’t do DST. UTC plus time zones isn’t enough for recurring meetings.
- ta1243 3y agoIf your meeting is 10AM Eastern, that's all you need. If your meeting is 10AM Dublin, that's all you need None of those timezones are half hour times. If you had a time at 10AM Delhi that would be fine too. Or 10AM Nepal.