For a long time GMT was a good reference point. Times have changed.
I used to work with a gentleman who would always schedule meetings on the phone as:
> Great, let's put that on the schedule for 2:00 o'clock Eastern Standard Time.
There was always a bit of officiousness to his tone and I think he just liked the idea of being precise.
And he certainly was precise. He was also off by an hour for half the year. Somehow no one ever missed a meeting, though.
I always sat on the other side of the room and ground my teeth.
It bugs me to no end when I have to select something like "-5:00 Eastern Time (US/Canada)" in those dialogs. I think a lot of people just don't care enough to truly understand time zones and there is enough flexibility in human communication to just absorb the endless ream of off-by-one-time-zone errors.
It's still something that I see on a regular basis, and it seems clear that I care more about it than others, because in my experience I talk about it more than others.
But the frameworks are not using standard IANA time zone names. Those look like "America/New_York".
The most recent time zone selection I made was installing OpenBSD on a new laptop yesterday. That had me choose a proper time zone name.
As best I can read your post you're implying that I am impugning the character of developers of applications I use. I have already noted very clearly that I think I just notice/care about this more.
You've also appealed to a couple sources of authority (framework maintainers and IANA). If I wanted to impugn the characters of those developers, I think I'd have good standing, as your authorities agree with me on proper time zone names. I don't want to do this, though. I don't think it's a big deal, because, as I've already mentioned, human communication offers much affordance for this type of technical incorrectness. I'm not confused. I doubt others are confused. I'm not frustrated. It just tickles the pedantic annoyance lever in my brain.
Wikipedia article: https://en.m.wikipedia.org/wiki/Tz_database
Tzinfo (note default examples using strings like I mentioned above): https://github.com/tzinfo/tzinfo/blob/master/README.md#examp...
Believe me, I'm having the same reaction right now.
> The most recent time zone selection I made was installing OpenBSD on a new laptop yesterday. That had me choose a proper time zone name.
If you don't understand the difference between you selecting "America/Los_Angeles" in an OpenBSD installation and the average user being confronted with a list of country/city names vs. a timezone name and offset then I feel sorry for your users.
If I were to put it in a UI, I'd try to have locally understandable time zones as the labels, without incorrect offsets. I'd also probably try to give a better than a drop down selection of multiple dozens of options. I might not succeed, in which case I'd fall back to some lowest common denominator based on a survey of popular services. In any event, I agree with you that it is not a high priority for me, and would not be in any app I might develop.
I'm just glad I don't need to have the "DST" talk more often. It takes people a night of sleep to process the level of time fuckery that is DST. Code reviews get delayed for a day when this happens. So yeah, when somebody refers to EST when they mean EDT I wouldn't give them "the talk". It works because people know what is meant.
Just a few days ago I had the understandable reaction of "what do you mean this won't work in India?"
More often I deal with fiscal calendars, rather than DST issues. The thing it takes them some time to realize is that their attempts to use date functions built around the standard calendar lead to huge pain when dealing with their weird fiscal calendar.
Whatever I assume, I might be off by an hour.