4 ms·
This is one of the easier things to handle in date time code. Take a localized date and time from the user, convert to utc, store that in one db field and the o
by notjoemama 3y ago
This is one of the easier things to handle in date time code. Take a localized date and time from the user, convert to utc, store that in one db field and the offset in another. It gets even easier if the TZ is a form option for an entity above the data being stored. To read you grab the utc date time, add the offset, grab the current time, convert to utc, add the offset, then do the comparison. That’s not much work for 100ks, a bit of work for millions, and a lot of work for billions. So real time must stay in the 100ks area, otherwise, do it in a background process and accept the cost. If you really need it, convert dates to big integers and do simple math. But check whether it makes a half order of magnitude difference in proc time. If not, move on.
- notjoemama 3y agoI’m forgot to mention, set TZ to GMT on the servers so your languages function calls get UTC be default.
- ta1243 3y agoI 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.
- 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.
- jayknight 3y agoThat doesn't work for recurring events. If you want the meeting to always happen at 09:00 in New York, you have to store the time and the "America/New York" time zone, then for each recurrence you translate to local time for each user/participant.