3 ms·

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 whe

by 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.
    - ta1243 3y ago
      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.
      - withinboredom 3y ago
        You aren't reading what I wrote. 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.

by ta1243 3y ago

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.
  - ta1243 3y ago
    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.
    - withinboredom 3y ago
      You aren't reading what I wrote. 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.