6 ms·

Why can't Google just use UTC timestamps? Or at least include them alongside their "US/Pacific" timestamps. I don't want to remember if "US/Pacific" currently

Why can't Google just use UTC timestamps? Or at least include them alongside their "US/Pacific" timestamps. I don't want to remember if "US/Pacific" currently has daylight savings or not. Its a very strange decision especially considering that GCP has numerous regions outside of "US/Pacific".

_wmd 8y ago
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
- stingraycharles 8y ago
  What’s the source of this? Is sounds intruiging, I wonder what led them to that decision.
  - _wmd 8y ago
    Just ask any current/former employee, it's practically folklore by now (i.e. knowledge older than 6 months)
    - puzzle 8y ago
      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: https://imgur.com/a/ZRtt9 https://imgur.com/a/ZRtt9 The leap second troubles in 2005 (GFS?) that led to NTP smearing were more memorable.
      - reaperducer 8y ago
        Google Standard Time Wow. Just... wow. Thanks for that. That phrase brought back a flood of old memories I'd forgotten.
  - puzzle 8y ago
    I wasn't around at the time, but I suspect it's mainly because the first datacenters were on the West Coast. See e.g. the story at http://www.dodgycoder.net/2013/02/googles-fiber-leeching-caper.html http://www.dodgycoder.net/2013/02/googles-fiber-leeching-cap...
- ngrilly 8y ago
  "Idiotic culture" is a bit harsh.
  - _wmd 8y ago
    You clearly haven't spent much time with App Engine
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
- manigandham 8y ago
  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.
  - chronid 8y ago
    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...
    - manigandham 8y ago
      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.
    - outworlder 8y ago
      > 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).
      - 8y ago
- strange_quark 8y ago
  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?
  - enraged_camel 8y ago
    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?
    - tazjin 8y ago
      Slack is not particularly known for caring about bloat in their pages.
      - ishansharma 8y ago
        Or apps for that matter. Having used the app for 6 months, I just keep a browser tab open these days, no use of feeding all the RAM to Slack.
        sitkack 8y ago
        We are going to find out the Hynix is a major stockholder in Slack. Mystery Solved.
      - enraged_camel 8y ago
        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?
      - scrumbledober 8y ago
        Or for rarely having outages...
    - 8y ago
- endymi0n 8y ago
  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.
sebazzz 8y ago
Perhaps they tend to think the US/Pacific time zone is the most significant timezone?
- delecti 8y ago
  It's probably not outrageous to assert that there are more devs looking up GCP information from that time zone than any other.
shafte 8y ago
This is fairly common for large tech companies that started in that timezone. The decisionmaking process goes something like this: 1. You MUST use a single, consistent timezone. Using the local timezone is a mess: is it the user's local? The host's local? What about server logs, which are typically text files where the timezone can't be displayed dynamically? What if you aggregate server logs across timezones? What if you ssh into a machine in a different timezone? 2. The logical timezone to use is the one in which the vast majority of your employees work, since having people subtracting 7/8 all the time is annoying. You could argue that for customer-facing status updates like this, Google should use a dynamic timezone. That's fair, but I'm sure Google internally uses that status dashboard, so it could be very confusing and complicate coordination to mitigate the problem. I'd argue that customers would prefer that the problem get fixed slightly sooner over having to do a once-a-year-ish timezone conversion.
- djhworld 8y ago
  > 1. You MUST use a single, consistent timezone. UTC was adopted 51 years ago.
  - shafte 8y ago
    As I said: UTC is a reasonable choice, except for the fact that most of your employees do not live in UTC and doing mental translation is annoying.
    - outworlder 8y ago
      Who is doing mental translation and why? We have computers for a reason. Are we talking about logs, software applications? Storage should be in UTC, data can be converted for display. I agree that logs can be a bit annoying when they are in UTC, but at least you have a consistent value across all servers, and you know what the offset is. Also, if your office happens to be in a timezone which observes DST, you are still screwed. Now you think your times are in localtime, but in fact they are offset by one hour. This can lead to very "fun" debugging sessions and time wasted. It can be a minor annoyance, but you know what can be an even greater annoyance? Undoing a bad decision which has percolated across several data stores.
yen223 8y ago
I'm glad they even included the timezone. An alarming number of tech posts don't even bother with that.

_wmd 8y ago

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

stingraycharles 8y ago
What’s the source of this? Is sounds intruiging, I wonder what led them to that decision.
- _wmd 8y ago
  Just ask any current/former employee, it's practically folklore by now (i.e. knowledge older than 6 months)
  - puzzle 8y ago
    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: https://imgur.com/a/ZRtt9 https://imgur.com/a/ZRtt9 The leap second troubles in 2005 (GFS?) that led to NTP smearing were more memorable.
    - reaperducer 8y ago
      Google Standard Time Wow. Just... wow. Thanks for that. That phrase brought back a flood of old memories I'd forgotten.
- puzzle 8y ago
  I wasn't around at the time, but I suspect it's mainly because the first datacenters were on the West Coast. See e.g. the story at http://www.dodgycoder.net/2013/02/googles-fiber-leeching-caper.html http://www.dodgycoder.net/2013/02/googles-fiber-leeching-cap...
ngrilly 8y ago
"Idiotic culture" is a bit harsh.
- _wmd 8y ago
  You clearly haven't spent much time with App Engine
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
manigandham 8y ago
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.
- chronid 8y ago
  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...
  - manigandham 8y ago
    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.
  - outworlder 8y ago
    > 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).
    - 8y ago
strange_quark 8y ago
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?
- enraged_camel 8y ago
  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?
  - tazjin 8y ago
    Slack is not particularly known for caring about bloat in their pages.
    - ishansharma 8y ago
      Or apps for that matter. Having used the app for 6 months, I just keep a browser tab open these days, no use of feeding all the RAM to Slack.
      - sitkack 8y ago
        We are going to find out the Hynix is a major stockholder in Slack. Mystery Solved.
    - enraged_camel 8y ago
      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?
    - scrumbledober 8y ago
      Or for rarely having outages...
  - 8y ago
endymi0n 8y ago
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.

sebazzz 8y ago

Perhaps they tend to think the US/Pacific time zone is the most significant timezone?

delecti 8y ago
It's probably not outrageous to assert that there are more devs looking up GCP information from that time zone than any other.

shafte 8y ago

This is fairly common for large tech companies that started in that timezone. The decisionmaking process goes something like this: 1. You MUST use a single, consistent timezone. Using the local timezone is a mess: is it the user's local? The host's local? What about server logs, which are typically text files where the timezone can't be displayed dynamically? What if you aggregate server logs across timezones? What if you ssh into a machine in a different timezone? 2. The logical timezone to use is the one in which the vast majority of your employees work, since having people subtracting 7/8 all the time is annoying. You could argue that for customer-facing status updates like this, Google should use a dynamic timezone. That's fair, but I'm sure Google internally uses that status dashboard, so it could be very confusing and complicate coordination to mitigate the problem. I'd argue that customers would prefer that the problem get fixed slightly sooner over having to do a once-a-year-ish timezone conversion.

djhworld 8y ago
> 1. You MUST use a single, consistent timezone. UTC was adopted 51 years ago.
- shafte 8y ago
  As I said: UTC is a reasonable choice, except for the fact that most of your employees do not live in UTC and doing mental translation is annoying.
  - outworlder 8y ago
    Who is doing mental translation and why? We have computers for a reason. Are we talking about logs, software applications? Storage should be in UTC, data can be converted for display. I agree that logs can be a bit annoying when they are in UTC, but at least you have a consistent value across all servers, and you know what the offset is. Also, if your office happens to be in a timezone which observes DST, you are still screwed. Now you think your times are in localtime, but in fact they are offset by one hour. This can lead to very "fun" debugging sessions and time wasted. It can be a minor annoyance, but you know what can be an even greater annoyance? Undoing a bad decision which has percolated across several data stores.

yen223 8y ago

I'm glad they even included the timezone. An alarming number of tech posts don't even bother with that.