[greggyb]

And an additional observation. Many applications that allow a user to pick their time zone typically show offsets from UTC and a time zone name.

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.

[scruple]

Isn't that more likely to be an artifact of some framework or library? I have a less than zero interest in creating or maintaining any list of timezones myself, I can tell you that. Besides, if I'm not mistaken, Rails, for instance, is using TZInfo underneath, which is an IANA timezone database. I have to imagine that any other self-respecting web framework is going to also provide things like this out of the box.

[greggyb]

Sure. It probably is. I'm not sure what the point is.

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

[scruple]

> I'm not sure what the point is.

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.

[greggyb]

Luckily, I get to avoid building time zone UIs in my day job.

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.

[lolc]

Few people appreciate the difference between timezones and their UTC offset at a given date. That's because it's very unattractive to learn about DST. Without that, timezone offsets are relatively stable and it wouldn't matter (in the short term) which one you'd work with.

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

[greggyb]

I steer into the skid. I've acquired several clients by giving talks on implementing time intelligence on several analytics platforms.

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.