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.
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.
> 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.
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.
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.
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.