If your company is entirely located in California or some other Pacific Time location, consider putting your servers on Arizona time. There's no daylight saving, and for most of the year, the server time will match your wristwatch. In the winter, when California is on PST, the servers will only be off by an hour.
I find that much more tolerable than the hassles of UTC servers, where you can't instantly translate between server time and wall time in your head, and server midnight rolls over in the middle of the California day, and thus datestamped logfiles don't match up at all with your wall calendar.
Edit: If you're going to downvote, please post a comment explaining why, so that readers can learn something.
Background: we moved all our pan-US servers ( Windows, Unix, AS/400 and MF ) to UTC back in the early 2000s, instead of following the local TZs.
I didn't experience any particular instance when I wanted to convert a server incident to wall-time. Since all events were scheduled in UTC it was a direct look-up between (1) unusual things happening on server and (2) any jobs scheduled at that time. What time it was in the office or in the customer's TZ didn't really matter.
The only time we converted to wall-time was internally within teams to determine when our maintenance shifts would start. With globally-outsourced support teams, the server load charts dictated the UTC time to start the work which was communicated to the appropriate teams who performed local conversion for their shifts. Once they were in the office, everything was executed on UTC.
Not this one:
>> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC, causing more crazy bugs, because for 8 hours a day, calling now() in the database has a different date from the application that talks to it.
If your servers and applications are both on Arizona time, it doesn't manifest itself.
$ TZ='<UTC-7>+7' date -R
Sat, 16 Jul 2016 11:04:52 -0700
$ TZ=:America/Hermosillo date -R
Sat, 16 Jul 2016 11:05:39 -0700
$ TZ=:Pacific/Pitcairn date -R
Sat, 16 Jul 2016 10:06:23 -0800
TAI: https://en.wikipedia.org/wiki/International_Atomic_Time
Cron is one example. It isn't trivial or intuitive to set up your crontabs in UTC; it should be, because that makes the most sense on a server (especially during DST transitions), but since it isn't, you either have to set your system time to UTC (as the article suggests), hack around it (changing the cron program on all machines you care about), or be aware of the pitfalls (like DST transitions).
The CRON_TZ specifies the time zone specific for the cron table. User type into the chosen table times in the time of the specified time zone. The time into log is taken from local time zone, where is the daemon running.
I use this all the time to set job times relative to a specific timezone while the server time is in UTC. It is trivial and makes setting the times largely intuitive.
Logfiles would be written with UTC times, but the time showing on my terminal prompt, or if I ran `date`, was in my local time.
(Possibly more confusing to me, as I live in Western and Northern Europe, with +0000, +0100 and +0200, so it's easy not to notice the time is offset from UTC in a logfile.)
If you're storing time stamps (i.e. you care about how many seconds have elapsed / will elapse since / until the event), your strategy is the right way to go.
For example, if you have a flight leaving SFO at July 16, 2016 4:00 PM PDT, you don't want to show it as July 16, 2016 1:00 PM if viewing it from New York.
> DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems
That's mostly just an argument for using the same timezone in all of your systems.
> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC
Same deal.
> There are thousands of bugs out there that are caused by timezones
A google search for any other word + bug is going to give you plenty of hits too.
> UTC assuming code interacting with non UTC assuming code can, and has caused silent data corruption
This is an argument for non-naive datetimes. Also is the same regardless of the two timezones involved.
> migrating later than the start of the infrastructure can be really painful, because of your app getting coupled to the timezone it’s in.
That's an argument for not changing timezones, rather than using UTC.
The other couple arguments are similarly moot.
While UTC is good, I think the key is really using consistent date handling. The most important bit is how you store them in the database, and in that regard I'm a fan of fully-non-ambiguous storage. That means either unix timestamps, or timezone-aware datetimes. Ambiguity by assuming a datetime everywhere from a data perspective is where you'll create confusion.
> That's mostly just an argument for using the same timezone in all of your systems.
The TZ database is not static. Governments have a habit of monkeying with DST definitions to suit their whims. Several of your systems may have TZ updates come out at different times. Debian/java/erlang/windows have different rollouts for the TZ database that you have to coordinate somehow if you want all your systems to agree on the time/date.
Just use UTC.
you're often asked on the setup script, but it mostly defaults to utc if you do an automatic installation and don't specify the timezone.
But I need to use moment.js to display the correct time with UTC. Is there a way to handle multi timezone users without external library?
If you want to display dates in another timezone you need to use a library that does that for you or write a function that adds/subtracts hours/minutes based on the offset.
I'd recommend using a library.
I see headers like this in GMail:
Received: … Sat, 16 Jul 2016 10:35:05 -0700 (PDT)
The same offset is in headers from Facebook and Microsoft, though Oracle have UTC.
Does anyone have experience with changing timezone of a server?
The only time I have seen time related errors when I extracting a tar file that had a future timestamp.
I only heard about the early-boot issue wish separate /usr partition. Is there anything else?
As for early-boot issue - I'd say it's uncommon to have /usr on separate partition from / nowadays, and those who do this must know what they're doing. Less likely to happen than ad-hoc manual (non-packaged) tzdata update not catching up.
I wrote a simple tool to translate timestamps between timezones on the fly when viewing files, although I've only used it personally, so I am sure there are plenty of bugs. Might be useful to someone else (or roll your own improved version).
> Setting the timezone to anything other than UTC