Semi-related: if you ever feel the need to report times to a global audience, not only make sure to always report the timezone (even if it is the same as the user's), but also use UTC offsets rather than timezone names.
Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.
It's also not too complicated to add a few lines of javascript that show the datet/time in the user's local time zone (via Date.getTimezoneOffset) as well.
GCP's various products have gotten a lot better at this lately, but just a few months ago I could click around between various dashboards and explorers, some showing the time in UTC, some in your browser's tz, and some in your profile's tz (if I recall correctly). Some of them were showing the tz, and for some you had to guess. Sometimes you had multiple tzs on the same page. Sometimes the date picker for a control was in one tz and the widget it was controlling in another (leading to quite a lot of confusion).
The worst offence IMO was not showing the tz at all. Especially given the overall lack of consistency.
We do this in all of our web apps. It's pretty simple and dramatically improves UX when you have customers that are doing a lot of scheduling.
Showing both at the same time is peak design for me personally. UTC compares for relative sequencing, local time for "was that before or after I ate lunch".
still show the timezone it's displayed in, users aren't always fully aware of which time zone their browser is believing they are in (sounds stupid at first but imagine you just traveled somewhere and are temporary used to that time zone but e.g. your laptop is fixed set to your home time zone, or maybe it's not and you just thought it is, or maybe you are just a bit confused because you switched time zones 4 times the last 24 hours etc.)
Also report it using IATA time zones (America/Los_Angeles) at least in addition (I'd argue instead of) those abbreviations which are completely unstandardized and not unique.
If the world were fair, we’d be calling these Eggert time zones, as Paul Eggert (longtime tzdata maintainer until the copyright trolls came) invented them; but it isn’t.
(You probably still meant IANA the Internet org not IATA the aviation one.)
Everyone knows "Mountain Time". It is when you go to the mountains on vacation, and don't spend much time adhering to a strict schedule, instead taking leisurely strolls around the fields and promising vague things like "I'll try to be back for dinner".
3 years ago, when I started work for my current employer, I noticed in Slack that everyone was reckoning time in "Standard Time" year-round. Now imagine my chagrin because I live in Arizona, and "Mountain Standard Time" does not change for DST. Therefore, all my coworkers were citing nonsensical, nonexistent time zones and it was messing up my ability to convert back and forth.
Come to find out that this was some sort of entrenched, company-wide standard that was deliberately imposed. I made a lot of noise about this and appealed to some rather highly-placed directors, because I felt like it was wildly inaccurate and deceiving people; if you schedule a meeting in EDT but you say it's in EST, and we have employees all around the world, who's going to know? You're inviting off-by-one errors. Especially with me who lives permanently in MST.
3 years on, I've been unable to change this fundamentally; while a few people acknowledge DST, 90% of the company still adheres to this crazy false standard.
I just had someone asking me if I'm available at 5pm EST.
Also, your clock can get confused driving North from PHX to Zion National Park.
In summer you start in Mountain Standard Time, drive into the Navajo Nation which does observe Mountain Daylight Time, containing through the Hopi Reservation, which is Mountain Standard Time. Then you end up back in Navajo Nation with Mountain Daylight Time. You keep on driving towards Page which is in Mountain Standard Time. However, when you cross the state-border of AZ/UT you're back in Mountain Daylight Time.
How does this generate off-by-one errors? I am also part of a company with employees in pretty much every timezone, but when they create a meeting the meeting invitation is programmed with the correct timezone so in my Calendar it always shows what time the meeting is going to be for me. I never even have to think what timezone the organizer is...
The off-by-one error occurs when you announce an event in Standard time but really mean Daylight time, or vice versa. While those local to the time zone will often automatically correct this mistake either consciously on unconsciously, those in other time zones (especially where Daylight time isn't used or is on a different schedule) will tend to rely on time conversion tools which will take a literal interpretation of the scheduled time and result in the person being an hour early or an hour late.
The fact that you have to announce timezones is already an error. If I need to schedule a meeting I don't need to select timezones, they're already selected from the timezone I'm part of. There's never room for error by "picking" the wrong thing, since there's nothing to pick. And if my system is programmed with the wrong timezone, then every single meeting will be off-by-N and my calendar will show the wrong time as "now". It would be impossible to miss such an error.
I think your company needs better tools to handle meetings.
It's the same at my company. Teams and Zoom both automatically schedule meetings in every attendees' own time zone. Maybe that person's company still does phone meetings or something.
We don't use any automatic scheduling with Zoom or Google Calendar. Management doesn't send invites to those meetings, they just publish the link on Slack and we have to figure out how to get it into our calendars.
Trust me, at least once I missed a meeting because I was late by an hour due to time zone confusion.
I mostly struggle with Irish Standard Time (used for DST in Ireland) and Indian Standard Time which have the same acronym. :(
Thankfully, I learnt a long time ago to use ISO 8601 and UTC for dates and times. I still revert to PST/PDT if my audience is primarily left coast based.
And I can't say it's ever actually caused a problem, but something about Indian Standard Time being a half-hour offset from UTC has always bothered me so much... But now we're fully off-topic.
And if you've been American since birth, and live in Arizona, one might still not know, since PDT and Mountain Time alternate covering Arizona seasonally. ("Ask me how i know.")
It can also varies within Arizona... one of the most confusing times in my life was driving from California through the Navajo Reservation in AZ on my way to an appointment. Was my cell phone giving me the local time on the reservation? Was it connecting to a cell tower just outside the reservation, giving me DST-less Arizona time? Or a tower slightly further away in Utah (DST?) Or was it giving me the time on the Hopi reservation, which is an enclave totally surrounded by the Navajo Reservation which uses AZ time?
Even in Australia, AEST has a DST flavour and a non-DST one. Queensland does not observe DST while the other states do. You can drive around a roundabout at the border and switch timezones for fun. Or go down there to celebrate the new year twice.
Or go from rabbits being OK to some 5 figure fine if you're caught with one :)
> Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.
Many people also get the timezone names completely wrong. I've had multiple scheduling email exchanges where someone says X pm EST not realizing that at the time it's currently EDT and that EST ≠ EDT.
And yet, for some reason, the two-letter abbreviations (e.g., ET) that are technically correct year-round, never seem to have caught on in the wild.
I've given up on the abbreviations and just say "Eastern" now to avoid confusion.
Fair enough, but please only use that with strictly USA audiences. (And remember that public information likely will not be targeted to strictly USA audiences)
Names don't carry any information intrinsically, they are only a reference to the actual information, and the offset information is pretty short, so why not just provide the information directly?
"X pm GMT-3" only requires the reader to know their own timezone offset, unlike "X pm Brasilia time" (which is inaccurately known as São Paulo time outside Brazil) or "X pm BRT", which requires the reader to both know what that timezone means, and their own (or, more likely, requires them to look the conversion up).
(And if the difference between GMT and UTC is significant, I hope it didn't take my comment to convince you about using offsets :> )
UTC is human readable even if it is not calculated correctly. yes, i'm saying that if you can read epoch seconds, you're not human. 1970-01-01 00:00:00 is always a give away that something is a foot
"anchored on" then? I might be wrong but we're both talking about showing time as distance from the same starting point are we not? One's just more human readable so that's why I say why not just use that? Seconds since can be miscalculated too, especially if current time isn't known/reliable
Nothing worse than people who say "9 AM my time" I suppose it's OK if it's Pacific vs Mountain but even there Arizona doesn't observe Daylight, and parts of Eastern Oregon are Mountain, not Pacific.
Never mind dealing with India, Australia, etc etc.
OK to use local time in your statement, just say what that time is.
The inconsistency with timezones across different services in the AWS console has always baffled and annoyed me. Some places have a time without a timezone and I can never tell right away if it's utc, local time, or region time.
> The inconsistency [of everything, everywhere] in the AWS console
ftfy
AWS is powerful and very popular, but for the console, "it functions" must be the only condition the UI has to satisfy. Should every page use a unique table and sorting widget and UI language? Yes, please!
I'm assuming this helps them move fast, not having to coordinate with anybody or wait for a UI designer to tell them how it should look. But it's striking when compared to GCP.
Technically PDT is always 7 hours behind UTC. PST is always 8 hours behind. We just change which one we use twice a year. Pacific time makes sense when you realize Fremont is the center of the universe.
Yup, this is why I always say “US ET” (I'm on the east coast). I don't trust myself or anyone else to get it right, and if the other party is converting anyway, their conversion tool (google?) should be able to handle that. (Of course, the date is necessary but implicit, but that's usually fine too.)
Indeed. There are Americans who will tell me PST, when they meant PDT but forgot to mention that. Now I have to track the American DST calendar as well as European DST calendar to do the conversion.
There are also people who tell me GMT (because they think that term means "the time in London") when they meant BST (because in summer, London doesn't operate on GMT).
The outage is in Virginia so PDT isn't even local time. On their status page they are asking users to access the console via a region specific endpoint like https://us-west-2.console.aws.amazon.com. Wonder if the PDT timestamp is because they have to serve the status page from US West right now.
The fact that which timezone is used in the announcement is a sign of progress... AWS announced it pretty quickly, gave nice updates, and seems to have fixed the problem quickly enough. I'm interested to see the postmortem...
When I was with AWS I advocate for ISO8601 "Z" whenever I could or need to influence, say internal systems.
If all systems talk this we'd save tens of thousands of man hours. Just do the conversion for us mortals, or other necessities. Tech side of incidents is definitely "system", I'd argue more often than not consumers of AWS are also tech side with systems in UTCs so health dashboards should also be a UTC first system. Doubt this could get prioritized tho
Imagine you have two browser opening the same page, one showing UTC, another showing your local time.
There are no indicator showing which time zone is used. You have to mentally correlate "this browser windows has logged in..." with the time shown on screen.
After spending some time in the Canary Islands I realized how nice it was to be in UTC all the time and now I have my laptop clock set to UTC. Still contemplating whether I should set Google Calendar and my smartwatch to UTC as well. 8-)
Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.