I have been guilty of this. I will sometimes use MST when I should use MDT due to muscle memory. And if I say MT it could be ambiguous when you consider Arizona (which doesn’t observe daylight savings).
I will not write “X city local time” though, I will take the extra time to make sure my timezone is correct.
Often "X city local time" is what you want though. If I schedule a recurring meeting at 1 PM, most people will expect it recur at 1 PM local time. A 1 PM EDT meeting would become noon EST when the clocks switch, and no-one wants a lunchtime meeting.
I worked on software that did this. Well prior to my starting there they defined “ET”, “CT”, “MT”, “PT” as the time zones you could set for a client.
Internally these had to be mapped to _real_ identifiers (aka America/New_York and friends). This fell apart though when Mexico (where we had some clients) shifted their DST dates about 2 weeks off from the US DST change.
The first time this happened all times were just off for 2 weeks. It caught everyone by surprise but trying to fix it would have been more dangerous than letting it be due to the nature of the software.
After we got past that, did we overhaul the system to use full identifiers in our config? Nope, we added “CT (Mexico)”. Timezones suck.
I will not write “X city local time” though, I will take the extra time to make sure my timezone is correct.