Just another case of their idiotic culture leaking into their products. An early "design" decision led to all their production kit being set to US/Pacific, triggering frequent DST bugs, and last I heard (many years ago) it was still the case.
Coordinating a tz change over a network of that size is probably infeasible, so may as well push the pain on to customers
Slack's status page does the same thing, and perhaps more insultingly, has a link that says "See in your timezone" that just links to timeanddate.com. Really? None of the 1000s of JS devs at Slack could figure out how to import a date/time library into their status page?
Just because you can import a library to do something doesn’t mean you should. Why bloat the software even more for a function that is used rarely (i.e. during outages) and by very few people?
That’s why I said “why should they bloat it even more”. I mean it’s already bloated and you want them to add more stuff just for an obscure little thing?
Seem reckless to use non-UTC time for anything as an engineering-focused team, but regardless they should definitely add some code to convert those times back to UTC for the rest of us.
Those were decisions made a lot of time ago, when there was only a single region/datacenter, since that was what you were running your servers on. And then they remained.
AWS has a similar issue internally, IIRC (oncall around DST switching times was fun with teams in three continents), but they are making baby steps to fix it. It's harder to fix than it sounds once in place though...
> Those were decisions made a lot of time ago, when there was only a single region/datacenter, since that was what you were running your servers on. And then they remained.
Yes, and it's still a <bad adjective here> decision. Actually, there should be no decisions on those things. It doesn't matter if it is your personal blog. Store events in UTC, no ifs or buts. Then convert for display. You better be able to fully articulate why you are not using UTC (scheduling real world events?), otherwise use UTC. Make it a tattoo if that helps. Again, UTC. Yes I know you are a single person and you don't have more than one server today, still use UTC. Thank your former self later on when you have to match events across timezones...
Text representation is another example. Use Unicode for strings unless you can clearly explain why that's the wrong representation. (Which Unicode? Pick UTF-8, unless you have a reason not to, in which case you'll probably know what the reason is).
You are talking about a decision that was made 18-20 years ago. It was bad decision in hindsight, but back then I'd imagine they were likely optimizing for a very different problem.
Even the UTF-8/Unicode example doesn't hold 18-20 years ago. UTF-8 was completely niche in 2003 and there were a number of flavors of Unicode, not all of which nicely fellback to ASCII like UTF-8 does. If I'm distributing software in 2003, I would have stuck to ASCII unless I was sure I needed Unicode, and if then I would have likely opted for UTF-16 because that was what was supported then.
I wouldn't question anyones decision for using UTF-16 in 2018 for software that had been supported since 2003.
> You are talking about a decision that was made 18-20 years ago.
Hang on.. what are we talking about?
According to Wikipedia, AWS was launched in 2006, which is only 12 years ago, and GCP was launched in 2008, only 10 years ago.
You could argue that, even in 2006, UTF-8 wasn't firmly enough established as the "winner" to be a clear best choice, but defending an for avoiding Unicode entirely at that point, for a company with global ambitions, just seems disingenuous.
For the question of UTC, claiming naivete also lacks credibility, if only because Y2K brought to and kept at the forefront of everyone's minds the topic of date/time representation in computers, starting around 20 years ago.
Although what you point out may be technically (and marketingly) correct, it's not a stretch to consider the current, cloud-computing AWS to have started until the availability of S3 and/or EC2.
More importantly, for these services to run roughshod, two years later, over the technical assumptions of something like AWIS also seems reasonable to expect. If AWIS isn't integrated under IAMs, that's pretty telling.
GCP inherited the decision from google's existing way of setting up servers, and they'd been setting up servers long since... or are you suggesting GCP should have run its servers with a different tz configuration than the rest of the company resulting in even worse issues?
Comments like yours really piss me off. You have absolutely no self-awareness or empathy, and come off sounding like a know it all.
Yes, we all know that storing date/time data is hard; they should use a standard timezone (without DST), and use time-locales to localize the timestamps to the user. We get it.
The reason this knowledge is so well known is because previous programmers (without this helpful guidance) made many different technical decisions for many reasons, and learned the hard way. They then publicized their failures for our benefit.
What was the last technical decision you made that turned out to be the wrong one? Did you make the wrong decision maliciously? Or were you doing the best you could with the information available? Would you really find it helpful for somebody to come along a decade later with the attitude "these guys have no idea what they were doing, I learned about these antipatterns years ago!" (usually followed by "better rewrite everything")
I'll go out on a limb and say most people here haven't started from a single datacenter and grew to a global service. These engineers deserve the benefit of doubt unless and until more information is available. They certainly don't need armchair analysis from some randos on hackernews.
>> we all know that storing date/time data is hard
But... it's not hard. That's the point. This isn't a hard decision and has nothing to do with regional vs global. The lesson was learned by the entire industry decades before the company existed so a modern engineering team making that mistake, and never fixing it, is definitely open for criticism.
Is it really believable that this engineering team started out by not thinking that their service (GCP) would become a global service, irrespective of how many datacenters they started with and where?
> Comments like yours really piss me off. You have absolutely no self-awareness or empathy, and come off sounding like a know it all.
Oh dear. This kind of personal attack is not ok on HN and we ban accounts that do this. Could you please not do it again, regardless of how un-self-aware another comment seems or how you feel in response?
Your comment would be fine without the first and last sentences. It's hard never to write such things but it's always possible to edit them out. That's what I do when something like that slips out.
I see where you're coming from on the first sentence. I should have left it at saying his comment seemed to lack empathy. The last sentence I still think is fine though (I include myself in the list of people who don't have the perspective to criticize their decisions, I don't have the context to be constructive). I won't defend the other comment.
It's easy to be unnecessarily rude in comments, but I would have said the same were we talking in person. I don't believe in hiding behind anonymity to say something you wouldn't say otherwise.
Sure, but we're just talking about the status site, it's not hard at all to just convert the timestamps to UTC for display using any server-side or JS library. Even better to show UTC and the current browser reported timezone alongside.
This goes deep within the UX of their systems - some of the most frequent actions in Stackdriver like jumping to a time within the logs is a mess. There are no quick actions (like "jump to now"), and THEN I have to switch to a non-intuitive "World / Greenwich Mean Time" config first every time (standard is Pacific, there is no UTC), and THEN I have to twist my brain into the weird US date format and AM/PM times within two different controls. Nothing of that is changeable or configurable, that interface is just a pain to use. My bug report apparently also didn't cut it.
Ten years ago it was called jokingly GST: not Gulf Standard Time, but Google Standard Time. I don't remember outages, but the monitoring graphs when switching to DST, where plots go back in time, did look very funky. Something like this:
Coordinating a tz change over a network of that size is probably infeasible, so may as well push the pain on to customers