For those wondering: Currently PDT is 7 hours behind UTC.
AWS can do so many things, reporting critical outage updates in UTC is not one of those things.
AWS can do so many things, reporting critical outage updates in UTC is not one of those things.
Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.
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
time encoded as a float of trecenti-seconds since year -8435 of the Georgian Calendar
why?
'caus it hurt to even just think about implementing that anywhere
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.
Heh. After the first few instance of confusion, we switched to saying Bangalore time and Dublin time.
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.
Trust me, at least once I missed a meeting because I was late by an hour due to time zone confusion.
I think your company needs better tools to handle meetings.
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.
My clock threw a segmentation fault.
I encourage everyone at my company to do the same. Easy way to eliminate errors while typing 1 less key stroke!
I literally had cases when I was woken up in the middle of the night for production issue because some people are too sloppy about this kind of thing.
Or go from rabbits being OK to some 5 figure fine if you're caught with one :)
date: illegal option -- I
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format] The -I flag was added in FreeBSD 12.0.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".
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.
(You probably still meant IANA the Internet org not IATA the aviation one.)
Never mind dealing with India, Australia, etc etc.
OK to use local time in your statement, just say what that time is.
- the keynote will start when this post is 5 hours old
- the rocket launch is scheduled to when this comment is 30 hours old
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.
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 :> )
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.
Thank you for reminding me about one of my biggest mildest annoyances from working at AWS.
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).
I have found this site very helpful for linking people to when they are confused or using them incorrectly:
The time zone comparison feature is nice as well:
https://time.is/compare/0800AM_14_June_2023_in_Cincinnati/Lo...
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
If you login, you can specify what timezone for timestamps and for the text to be parsed into your timezone preference.
https://health.aws.amazon.com/health/status#settings
As I'm logged in, it persists across browser sessions.
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.