Ha! I think you're still misunderstanding me. (Maybe misunderstanding me more than you were previously.)

We're not using any Google service in relation to the timezones things in question. You said in your post "They shouldn’t be returning MNT for Arizona because they aren’t in Mountain time." The only reason I mentioned Google is because after reading that sentence, I googled to see what timezone Arizona is in (because I thought I remembered it was in mountain time) and my Google search seems to confirm that Arizona is indeed in the mountain time zone.

If you have a store in Gilbert, AZ, set this column to America/Phoenix. Minneapolis would get America/Chicago etc.

Exactly what I'm getting at. They should be using the "America/Phoenix" format for identifying timezones, not "MST". But they use the latter and I don't have any control over the service in question because it's owned by another team. We could nag them, but they don't really have a lot of incentive to make such a fix, so realistically that task would probably die at the bottom of their backlog. My team only consumes data from the service in question. And because it's doing things in that way, my team has to have extra complexity in our code to account for it.

The talk I'm planning to give to my team isn't going to be related to any of that. My team also runs into timezone weirdness, of course, because so does every developer, and a better understanding about such things is definitely going to benefit everyone. That story about the other team using the three-letter abbreviations in stead of, say "America/Phoenix" was just me ranting about how things are done by other teams at the company where I work.