A few summers ago, there was an announcement about downtime for a commonly-used service.
Servers will be taken offline from 9am to 11am PST.
I suspected that this was another case of people thinking that standard time is just a formal way of saying local time.
I use that service a lot, and if it wasn’t going to be available in the morning, I needed to plan around it. The message also said, “For support use our chatbot.” So I went to the chatbot to confirm the time zone for the maintenance window.
The chatbot replied, “Sorry, I cannot help with outages or maintenance windows.” So chatbot doesn’t do the very thing they told us to use it for.
The announcement also said, “For more information, see this link.” So I went to the link.
The link is 404.
Now 0 for 2, I contacted the team directly. “Um, so that means 10am to noon Redmond local time (PDT)?”
Nope, they really meant 9am to 11am Redmond local time. They didn’t read the maintenance window times in their own announcement. People at remote offices will do the wrong time zone conversion.
I pointed out to them that their chatbot is unable to help with the very thing they directed people to use it for. And that their support link is broken. They said they’ll look into it.¹
The team sent out a follow-up announcement later that day clarifying that the downtime is 9am to 11am Redmond local time (PDT), not PST.
The next day, I received announcement that another popular service was going to be unavailable from 9am to 11am PST. I asked that second team to clarify whether the downtime really was 10am to noon Redmond local time, or whether they intended PDT rather than PST.
The second team wrote back and apologized for the error. Their service is dependent upon the first service, so they copied the downtime window from the first team’s announcement and pasted it into theirs. They must have missed the correction, so they copied the wrong information.
Two days later, I was part of an online group exercise, and the facilitator said that we would take a break and resume at 3:30 Pacific Standard Time. I commented in the group chat for the benefit of remote attendees that they probably meant Pacific Daylight Time, since that’s the current time zone in Redmond.
Time zones: They’re not just for sounding formal. They actually mean something. If you mean Redmond local time, then just say Redmond local time.
Most of the United States changes from Standard time to Daylight time this weekend.
¹ Narrator: “They didn’t look into it.”
I wonder how many other “S is for summer” time zones there are than Central European Summer Time.
PDT is 231 days long this year compared to 134 days for PST. So there is some weight for the longer period being the “standard”.
Do they really use CET, Central European Time, for the winter months? That sounds as bad as PT.
They do use "CET" which makes sense being the "normal" i.e. winter time, as opposed to the "artificially advanced" summer time. This is in contrast to PT which is a time zone with unspecified UTC offset.
There's also BST, British Summer Time, which is UTC+1. Not to be confused with Bangladesh Standard Time (UTC+6) or Burma Standard Time (UTC+6:30), both of which also use the abbreviation "BST".
In Ireland, as in the UK, they observe GMT in winter and Irish Standard Time in the summer. Not "Irish Summer Time", but "Irish Standard Time". So they have S for "Standard" but applying only...
Is there any timeline we can use for auto fetch ?
Just use UTC for God’s sake.
This problem is worse in the Mountain time zone, where there are states simultaneously observing MST and MDT. When I lived in eastern Indiana, before they adopted Daylight Saving Time (for the second time, since they effectively adopted it year-round back in the 40s) we had the same problem – Ohio observed EDT and Indiana observed EST. Most people I worked with said “Ohio time” or “Indiana time” but you always got that one person who wanted to sound smart and would say “EST” instead.
Hmm… A time zone, to me, is a region/geographical area. Having 2 time zones for the same region is…strange? I think in Europe they only use one time zone for one region (make perfect sense to me, but I am biased). When you write that many use PST incorrectly, it may seems they want to use it “correctly” too (meaning, use PST like it is the only time zone for that region, regardless of daylight saving).
There are basically two kinds of “time zones”: One is “a fixed offset from UTC”, those are e.g. “PST”, “CEST” (where the “S” means “Summer”, i.e. the exact opposite from the “S” in “PST”) “UTC-02:00”, etc. The other one is “the time observed in the given geographical area, however its offset from UTC changes throughout the year”, those are e.g. “America/Los_Angeles”, “Europe/Paris”, or “Pacific Time” (“PT”).
Wow, the previous essay on this topic was in 2012. Indeed, this problem occurs much more often than once a decade. However, readers of this blog are probably all to familiar with the issue.
In Spain it’s very common to say “Spanish time”, even though the country spans through two time zones. Of course, what they really mean is “Madrid time”, which is what they should be saying in the first place, because main cities are typically a very good reference, much better than named time zones that swap twice a year.
In my experience the time is the least of your worries. We publish APIs and every time we have a deployment, downtime or not, we specify what is changing and the impact it'll have on our clients. EVERY SINGLE TIME we do this we get a follow up email from at least one client asking the impact to them and whether we can defer it because they aren't ready for whatever change we made.
In every case we point out that we have no idea how they are using the API so we cannot determine the exact impact to them....
I see this more often from non-technical people who are trying to pretend to be technical. Any seasoned dev knows that time is prickly, dangerous territory.
Figuring out how to version your API so that you don’t break customers is an orthogonal problem. As is figuring out how to do deploys without downtime. As is a lack of decent PMs with customer use cases. Making software like it’s the 1990s is much more trouble than mere time zones.
Inside, I’m crying for you. It doesn’t have to be like that.
I can only assume that blaming customers instead of fixing engineering culture is approved by your management. You could consider leaving.
I can tell that you've not spent a huge amount of time supporting customers; back when I did, I'd get a request to defer a deployment because the client is "not ready" when we e-mailed as a courtesy to let them know that we intended to swap out servers one at a time for newer ones. This is purely routine maintenance, should have no client-visible impact, and we only notified people because it increased the chance that a human error at our end would result in increased service latency (procedure was to install new server, bring it up, add it...
Not sure what you’re talking about. We have neither downtime, for deployments, nor do we have versioning issues. We don’t break existing clients either. Our APIs are more solid, reliable and resilient then every other API our customers use, so they all say. They we get these emails on every release, irrelevant of what the email actually says.
This is not an engineering issue. This is customers not either fully reading the messages or understanding them and reaching out to us anyway.
Using UTC everywhere would force EVERYONE to think. Which, actually, is a GOOD thing. Would also make every programmer understand timezones before they even put their hands on the code. Before they even learn to write.
Noone will, though.
Everyone except people in London, Lisbon, etc, where local time is the same as UTC half the year
This. Properly configured servers do not have time zones or daylight saving. They operate in UTC. People, on the other hand, live in so many time zones that there isn’t any reason to single out just one in the announcement.
(The alternative is to use the HTML <time> element and leave it to the browser to assist the user in converting it to the local time. (As far as I know, no browser currently does anything like that.))
A person going by the handle qntm has explained the problems with global UTC far more thoroughly than I ever could. But I would summarize it as follows:
Humans are (mostly) diurnal creatures. At any given "real" (universal) time, different parts of the world observe different solar time (which is the technical term for "the time as would be reflected on a sundial, if we pretend that sundials continue to work at night, when it's cloudy, etc.," and I'm also leaving out a few technicalities that don't matter for the purposes of this discussion like mean vs. apparent solar time). From...
That’s why I just say “9-11am PT”
The servers will be down on November 2nd, between 2am and 3am PT.
1 letter here can save many emails.
Honestly, if I got an email that was describing a time window around the daylight savings change, even if they included a D or S in the abbreviation I wouldn’t be confident that the sender actually knew which one meant which.