[shafte]

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]

> 1. You MUST use a single, consistent timezone.

UTC was adopted 51 years ago.

[shafte]

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.

[manigandham]

Store UTC, convert on display to any timezone, either automatically based on geolocation or using a stored preference. This is application design 101 at this point.

Converting old logs isn't hard either since ISO timestamp formats include timezones, or just pick a date for the switchover. The only scenario that gets tricky is with scheduling where users expect local times that carry over daylight-savings boundaries, but it doesn't apply to most apps.

[outworlder]

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.

[sleepydog]

> Storage should be in UTC, data can be converted for display

Sometimes we need to speak about events (verbally), or share screenshots of graphs, dashboards, or other data. We can make a habit of always stating the time zone when we talk, and make sure every dashboard/graph contains a time offset.

Or we can just pick a single arbitrary time zone and always use that.

There are a few internal tools at Google that assume your local time zone (I'm in EDT) -- those are far more confusing.

> Also, if your office happens to be in a timezone which observes DST, you are still screwed.

Has this really been a problem? A date+time is unambiguous. I can only see this being confusing if California follows through with abolishing DST.

[manigandham]

>> Or we can just pick a single arbitrary time zone and always use that.

...so pick UTC then?

Why is that any different than how it is right now for anyone not in the Pacific timezone?

[lloydde]

I think they forgot to tell the PC kids. I seem to recall years of Unix/Linux installs prompting (tempting) me not to use UTC. I also seem to remember dual booting and Windows and Linux doing a time tug of war with some OS preferring the Real Time Clock (RTC) being local time.

[shub]

Windows likes local time on the RTC. Way back when DOS 1.0 was released (every story about Windows begins with this) there was one way to set the system clock: the user would type in the time. They would use the local time, of course. Consistency with other systems didn't mean diddly squat on a PC/XT with 256 KB of RAM, a floppy drive, and a keyboard. Fast forward a million tech years and we all live with the legacy.

[mrighele]

Windows use the local time zone (for historical reason, explained in the sibling comment), so if you dual boot it makes sense to keep the same behavior, otherwise you will have time issues when booting the other OS. If you only use Linux just go for UTC.

[toast0]

1) hah, Yahoo used US/Pacific for US servers, GB/London for European servers, and I never had access to Asia Pacific, but I assume something different there. Also, ads system/related graphing tools ran on US/Eastern, except without DST (because 24 hour days are important)

There was some talk of changing to UTC everywhere, but I'm not sure if that happened. The next two big companies I went to at least managed to run US/Pacific everywhere. But the problem is always, by the time someone who knows better comes along, it's a PITA to change.

[mmt]

> it's a PITA to change

Pain/annoyance is a recurring theme in this sub-thread as far as reasons go for not switching or not using UTC in the first place.

I strongly suspect, however, that this is one of those situation where the negative aspect is over-estimated.

Other times, merely debating/discussing it draws attention to the pain and serves to amplify it (or its perception). Just quietly implementing it risks offending key players, but the vast majority won't even know the difference.