Local timezones on servers considered harmful?

Question

I'm curious as to what other administrators' experiences with timezones, in the context of remotely administered servers, are. In my career I've come across several conventions;

1. Always, always, always use UTC.
2. Always, always, always use the timezone of wherever base HQ is.
3. Use the local time of the people who happen to be administering.
4. Use the local time of the server location.

In some places, I've come across multiple and conflicting conventions. My own preference has been to use UTC, always - with no daylight savings. But for one reason or another, it seems that most people prefer to use some concept of local time, with daylight savings. Although it seems like a straightforward technical matter, discussions around changing conventions always seem to trend towards religious schisms.

What are you using? What do you consider to be the advantages and disadvantages of each approach?

Answer 1

• Hardware clock should always be UTC. Always.
• Timezone as a setting can be whatever is convenient. Usually. Sometimes it should also be UTC.

Some reasons why UTC is nice:

• Daylight savings rules change, and updates do not always happen in a timely fashion. UTC makes this go away.
• When logs from servers in different location need to be compared, UTC makes a great common standard.
• Typically when servers are in different locations, either people or applications or both must deal with time conversions while performing, say, database inserts. If you have a single conversion (to UTC) then it's much easier to get right than if you must convert from one TZ to another, varying by server, TZ.

Answer 2

I prefer option 4. It's the responsibility of applications running on a server to decide whether to store DateTime values in UTC or not.

Also, when a server records system event logs, it's nice to be able to correlate local events with log entries. For example, if a data center reports a network disruption in local time, you can easily identify any issues that occurred without having to convert time values in your head.

Answer 3

No, no, a thousand times no.

There are two types of programmers... Those who understand that localtime should be used for display/formatting purposes only, and those that are painting themselves into a corner ... and they are painting with kerosene.

All events should be recorded in UTC, and the results converted to localtime only to display them to users. Damned are those who fail to do this, and doubly-damned are those who use localtime in a format that discards the timezone information (I'm looking at you, Oracle DBAs).

Think of it like a taint check... If you convert a timespec to localtime and then do anything with it that isn't emitting it to STDOUT, your program should not only exit with a fatal error, but also delete your source to teach you a lesson.

Answer 4

When given the choice, I like to keep the BIOS clock on UTC but the actual server time as local-time. We have no multi-timezone presence so unified log timestamping isn't the problem it would be for, say, 3M.

Answer 5

In my company, we had all the servers in a single TZ until this year. We now have servers in 3 new timezones. All the server run with our local timezone. This is pretty useful for log analysis, especially as we have distributed websites running across the 3 timezones.

However, in one special case, we have left a server with our customer TZ. The application is supposed to be up most of the day and the maintenance tasks are usually setup to run during the "night". At first, we set the server in our TZ but the maintenance tasks were slowing stuff too much for our beloved "we work when you sleep" customers...

UTC is also a very nice option. Unless people always refer to the local timezone when looking at logs (which is the case in here).

Answer 6

I run all my servers on UTC, and I convert any that come into my control as soon as I can.

The one exception so far has been an asterisk server, which I had to leave on local time. Changing it to UTC completely broke asterisk. (It's on 1.6, hopefully this won't be an issue when I get around to upgrading it later this year.)