[2T1Qka0rEiPr]

Weird aside question: I notice the article says "at approximately 10:00pm GMT". Can someone explain why GMT might be chosen as a reference point here? Is there something I'm missing about the usage of GMT (and not UTC). It just seems particularly odd given that GMT is not (to my knowledge) actually being used as a concrete time-zone at the minute (BST is in effect for daylight savings).

[greggyb]

I usually attribute it to mild ignorance, not in a bad way.

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.

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

[floatboth]

I guess people who aren't overly pedantic say "GMT" to mean "UTC", just like everyone says "SSL" when it's actually "TLS". Older but better sounding names stick around.

[s_ngularity]

In the UK, GMT is often used to refer to "the current British time" both GMT/BST. I've seen the same in the US where people say EST but mean EDT.

[rahimnathwani]

Whenever someone says GMT/PST/EST during the summer, I need to ask them to confirm whether they mean BST/PDT/EDT.

Whatever I assume, I might be off by an hour.

[2T1Qka0rEiPr]

Is it? I mean, I'm British and I'm not aware of this.

[stordoff]

I've seen a few people do it, but it's also usually corrected as been wrong.