101–110 of 331 posts
Earlier quoted context omitted.
just report it in epoch seconds
that's based on UTC, so just use UTC?
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
Earlier quoted context omitted.
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 usually extremely US-centric. Nobody outside of North America has any idea what "PDT" or "Mountain Time" means.
Why is it always us-east-1 though? I have always stayed away from that region because it seems significantly less reliable than other regions.
It's the: * Largest (DDoS'd most, most complex, scaling issues etc) * Oldest (More time for weird idiosyncrasies to take hold) * Where most testing happens * Where new products are deployed first
Earlier quoted context omitted.
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 usually extremely US-centric. Nobody outside of North America has any idea what "PDT" or "Mountain Time" means.
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.
Even management console is down, and their suggested region specific workaround does not work, at least for us-east-1. I can see some processes via api but I don't have code prepared for monitoring every service from my local.
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.
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.
Why is it always us-east-1 though? I have always stayed away from that region because it seems significantly less reliable than other regions.
It's the: * Largest (DDoS'd most, most complex, scaling issues etc) * Oldest (More time for weird idiosyncrasies to take hold) * Where most testing happens * Where new products are deployed first
Why does everyone keep deploying their products to this one region when it always seems like the one that fails? We don't use big cloud were I work, so maybe I'm missing something. Does East-1 offer something other don't?
Plus, as others have noted, there are critical AWS services in their control plan that only run in us-east-1 behind the scenes. So you're kind of out of luck.
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.