It gets even more interesting if you're tracking time while considering movement. First time I ran into this was timetracking aboard a ship that is at sea for multiple days. You can cross timezones repeatedly in both directions, the date line, can have a local start datetime that is after the local end datetime, etc.

You don't even need a ship to get into some real confusion.

Arizona is Mountain Standard Time, no day light savings.

Navajo Nation, which overlaps state of Arizona, is MST with DST (since much of it is outside Arizona, and that's more common).

Hopi Reservation, which is fully contained inside both of Navajo Nation and Arizona, is MST with no DST.

You can drive 35 miles from Gray Mountain, AZ (non-reservation) through Tuba City (Navajo Nation) to Moenkopi (Hopi Reservation) and experience noDST->DST->noDST in just over half an hour.

Continue southeast for 100 miles to experience a bonus noDST->DST->noDST->DST->noDST->DST transition.

If you rely on your phone's automatic clock adjustment, best of luck!

Is this logging or planning? If it's logging I would love to know the arguments against storing the records as timestamps.

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.

  > 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?

One 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.

I 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.

I 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.

Indeed. 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.

Definitely.

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.

> 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.

Not 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!