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.
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!
Dealing with timezones will drive you mad, quickly.