If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes.
Storing dates as UTC is appropriate for dates in the past, or future dates that a user will never expect to happen at a certain wall-clock time.
(An IANA zone name is something like America/New_York, and not EST or UTC-05:00)
Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC.
It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
Even my colleague in Arizona is able to follow this despite them not joining the daylight savings time.
Technically incorrect but in a way that doesn't inhibit understanding is the definition of pedantic.
I was just being pedantic about it being pedantic .
If it's the middle of July, and someone in California sets up a meeting with someone in New York, but tells them "9am PST", it would be understood to actually mean "PT" or "PDT". I suspect only certain kinds of neurodivergent people would show up for the meeting an hour off. And hopefully someone who genuinely thought PST was the intention would ask for clarification. Most people, though, who would bring it up do so just for reasons of pedantry, not because they're actually confused.
It's probably true that the <1% of people you hang out with most of the time can correct the error without even thinking about it because they live in California too. But that doesn't make it a pedantic error; it's an error that regularly has serious consequences, precisely because people's actual intent is misunderstood.
Most people don't know how tall five feet is, because they use the metric system, and they don't even speak English. Most people in California and New York know those things, and they're also likely to know that you don't really mean "PST" if you're talking about a date when California is on daylight time.
But most people don't know those things, and so if what you say is the opposite of what you mean, you can expect them to be confused when they look up the definition. If that's what you're shooting for, then by all means, go right ahead. But if you're trying for clear communication, you might want to get a little bit clearer about the kinds of things "most people" know and the kinds of things most people actually know.
Daylight savings time transitions cause me scheduling grief on a regular basis, not because I'm "neurodivergent" but just because I don't know what dates Belgium or California or Chile does their stupid clock changes, because I don't live there, and they all do them on separate dates.
In normal everyday usage, most of the time, people will understand by context and convention what is meant by "5:30" even without specifying AM or PM, let alone the timezone or TZDATA version associated. Yes, there are times specificity matters, and thinking about that can be goos, but the social frictions imposed may exceed any other benefits achieved, at least much of the time. At the same time, even where those ambiguities exist it's typically mentally jarring for people to be constantly reminded of this, even where they should be.
Where there's an opportunity for ambiguity, yes, nail down specifically what is meant. I read delecti's comment in that context, and note that they're describing themselves as the pedant. Which I interpret as "a stickler for accuracy and precision".
Mainly, though, it just annoys me: precision sans accuracy is bloody annoying.
Which is often what we want!
So on that regard, I find calendar invites rather than a causal email invite to be essential.
Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time.
Unless the other country decides to switch timezones, well then you are screwed.
Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities.
For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea.
To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
Of course, times sometimes do need timezones. But calendar dates (like Christmas, or your birthday) almost never do and having things automagically do adjustments based on that and give the wrong results is just a pain.
That's one thing I don't like about many standard libraries. They'll have a DateTime object that does all kinds of automagic stuff for you (or against you), but no concept of just a date itself. Many bugs occur between 2300 and 0100 due to that (and sometimes between 1100 and 1300 because people try to compensate for the buggy adjustments by setting the unwanted time component to noon).
Another problem arises when the server's timezone is set to X, the database's timezone is Y, the software's timezone is Z, and one user's entering data in timezone A while another is reading it in timezone B - and all of the software parts along the way are each trying to automagically adjust it. A good reason we should just all switch to UTC and drop the idea of timezones entirely.
Also some events aren’t related to human activity and you would rather not make that adjustment. It can be tricky to know which is which.
...9am of their timezone or 9am of other participants time zone ?
Countries also share a timezone, what happens when they stop ?
what if you store time in CEST but the date CEST changes into CET is different in different countries ?
People easily forget that others in a meeting loop are in different time zones.
Not so bad in parts Europe or the UK, but for those of us in countries with multiple TZs like the US and Australia, it’s a persistent problem!
Especially for those junior members who are new to the group video conferencing game!
Conveying TimeZones in software is also a UX issue I’ve found! People don’t really understand LOL
When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.