To some people, time zones are just a fancy way of sounding important, episode 2

devblogs.microsoft.com

15 points·Jaxkr··6 comments

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.

You rarely need to give a time zone when you schedule something with a physical location.

I always use PT for Pacific Time to avoid the PST/PDT confusion. It has worked so far.

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 use PT because I can’t remember which is the current and I don’t want to run a command to find out.

Reply on news.ycombinator.com