4 ms·

> 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.
  - sleepydog 8y ago
    > 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 8y ago
      >> 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?
- manigandham 8y ago
  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.
lloydde 8y ago
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 8y ago
  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 8y ago
  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.

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.
- sleepydog 8y ago
  > 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 8y ago
    >> 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?
manigandham 8y ago
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.

lloydde 8y ago

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 8y ago
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 8y ago
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.