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.