5 ms·
Are you suggesting to just make the calendar in UTC with zero timezones? I agree that they are something we created, but we created them for better local organi
by 0xEF 2y ago
Are you suggesting to just make the calendar in UTC with zero timezones? I agree that they are something we created, but we created them for better local organization. I work with customers globally and everyone uses them. This is a pretty ridiculous ask, in my opinion.
Rather just focus on eliminating the Daylight Savings concept from the few localization that still use it, as they tend to cause the most confusion across timezones, especially when planning past an upcoming shift.
- canucker2016 2y agoI did not say that. Timezones are not carved in stone. Prepare for that. A location could go from a +1/-1 timezone as in most of USA/Canada to a fixed timezone with no transitions. There are various ways to adapt, but the user-friendly way involves a lot more work in the app, especially if the app thought that timezone data wouldn't change.
- Lutger 2y agoIndeed. There are multiple timezone changes each year, causing gaps in time. Also, not every timezone is a neat 1 hour increment, some are 15 minutes or worse. There are even people living in the same geographical location but in different timezones! Dealing with timezones will drive you mad, quickly.
- canucker2016 2y agoDefinitely. The timezone inventors specified the timezone transitions would occur when most people weren't awake or affected - early in the day in the middle of a Saturday/Sunday weekend for USA/Canada. But remote teamwork threw a wrench in that. 2AM Sunday meetings sounded unlikely unless your team needs to communicate with a team several hours ahead or behind and Sunday is a regular workday for one of the teams.
- pantulis 2y ago> Dealing with timezones will drive you mad, quickly. I guess you mean "implementing timezone logic yourself". other than that, the suggested approach (store everything in UTC) and translating to the relevant user timezone with a TZ database in the frontend is the way to go.
- plibblr 2y agoNot sure, that's good advice for times in the past, or for times in the next few months, but if we're arranging to meet at midday local time in two years time, I don't think a change in timezone rules in 2025 should cause our meeting to take place at a different time. I suppose you could store the meeting in UTC and use the creation time of the meeting to decide to use the 2024 timezone rules for conversion not the 2026 rules, but that seems pretty confusing too!
- Lutger 2y agoOne approach is to store everything in UTC, and display in the timezone of the user. Dealing with timezones - including DST - properly is a must-have, no way around it. I live in a country that uses DST, a lot of Europe does that. If my calendar would be off by 1 hour half of the year, I'd consider it broken and seriously doubt the competence of its authors. This is the core domain of a calendar app! It would be like an email app that just silently drops every other email. I'd love for us to ditch DST by the way, hate it every time. Its bad for the economy, its bad for our health, its bad for software.
- dqv 2y agoI don't trust UTC for future dates, only for things that have already happened. Future dates are tentative in that their UTC representation can change. For example, if I converted a Kazakh user's event slated for April 1, 2024 to UTC before February 1, 2024, the event time would be off by one hour.
- dotancohen 2y ago> Rather just focus on eliminating the Daylight Savings concept from the few localization that still use it Oh, certainly, change the laws and cultures of foreign states and peoples in order to simplify your code. Can you get them to just write everything in ASCII while you're at it?