5 ms·

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 f

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.

withinboredom 3y ago
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.
- ta1243 3y ago
  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) 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 ago
    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.
    - 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.

withinboredom 3y ago

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.

ta1243 3y ago
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) 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 ago
  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.
  - 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.