This may not be a big deal for smaller shops that only have one or a few site, but for larger organizations this is something I'm curious about.

What are the pros and cons have having all/most of your server in UTC? It would certainly help in reporting and centralized logging. Also with event correlation for troubleshooting or security auditing. One also wouldn't have to worry as much about Daylight Saving Time changes.

One disadvantage could that scheduling automated events (e.g., cron) may take a bit of may if you want it to run something at "4 AM" in the local, geographic time. For Unix-y machine you could still have users be in the local timezone by setting "TZ" in /etc/profile, but for Windows users that RDesktop into a server (for whatever reason), are they stuck with looking at UTC?

  • There is a similar (older) thread running over at sage-members: http://mailman.sage.org/pipermail/sage-members/2010/msg00592.html – adamo Oct 15 '10 at 18:41
  • And of course since you posted the question on sage-members too, the (new) thread http://mailman.sage.org/pipermail/sage-members/2010/msg01194.html :) – adamo Oct 15 '10 at 18:44
  • 2
    UTC one time zone to rule them all ... –  Sep 27 '11 at 18:26

8 Answers8


As with most things, "it depends".

  • Are all of your administrators/users in the same timezone? Perhaps their TZ would be appropriate.
  • Do the machines interact with the local environment? Local TZ might be good.
  • Are all the logs pulled to a central location for analysis? UTC might help there.
  • Do the machines communicate with each other in ways where time matters? UTC might help prevent silly mismatch issues.
  • Does the OS vendor (more likely for network gear) have a suggestion? Consider that.
  • Will DST annoy you? Use UTC.
  • What do you think will make your life easier? Use that.

I've done all of the options (Local, UTC, arbitrary but consistent) and prefer the "local time to the home office for all machines" as that's where the sysadmins and users were, even though the machines were scattered all over the world.

  • 682
  • 4
  • 6
  • 4
    Well put - I'd add a couple more criteria. 1) If you have support organisations in multiple time zones, UTC everywhere will probably avoid confusion (in this case, having everything set to the 'home office' time zone will only serve to irritate people in other offices; never mind the confusion that ensues when DST kicks in. 2) If you have to deal with international vendors like telecoms carriers, many of them work in UTC; not having to convert the timestamps in your logs when you send them in will save a lot of time. – Murali Suriar Nov 18 '10 at 10:45
  • I have worked over different timezones with different servers. We had serious issues with a project once where data was being stored with the servers timezone set to DST and GMT.. not easy to fix. Not easy at all. UTC is your friend :) – John Hunt May 02 '13 at 11:53

We set everything to GMT, it makes correlating log files across systems simpler.

But I think we should drop time zones, and all use GMT for everything.

Ronald Pottol
  • 1,703
  • 1
  • 11
  • 19

As others have said, it depends. A very large group with lengthy and vast experience on this matter has weighed in. The group is the military forces around the world and they use UTC(GMT).

One other thing to consider. If these systems are supporting application code you meed to know if the applications are timezone aware. In some of the programming forums I participate in I suggest that date/times always be stored in UTC in the database, and give the end-user the option of how they see the date / time.

  • 683
  • 5
  • 11

I work for a very large hosting company, and we have datacenters worldwide. We generally set machine time to local datacenter time, and then use the timezone where all our support personnel are located as the universal time that things are converted to when using tools, etc.

As others have said, there's no one right answer, but that's the method we use:)

  • 8,380
  • 1
  • 31
  • 30

Policy here says all machines are timzoned to their local timezone (i.e. physical location). The only thing tricky is correlating event log entries (windows machiens) as the time is give nlocal - most other logfiles write the time in UTC anyway.

but for Windows users that RDesktop into a server (for whatever reason), are they stuck with looking at UTC?

Not totally sure, but I think yes - the timezone is logically a machine level setting.

  • 51,649
  • 7
  • 54
  • 136

We have machines physically located in one timezone that are set for 3 hours ahead because of the application they support.

We also have developers who build software expecting sub-five-second synchrony between servers, developers who implicitly rely upon AD time for sync, and who dodn't bother to write error-checking or handling routines for non-sync cases, and who assert that subsequent failures are the fault of the admins for not maintaining network time to the standard they were imagining..

Don't do what we did. It will just make you bitter.

  • 1,769
  • 12
  • 14

Just to add to the discussion, we have offices scattered all over the world and each of them have their own set of web, application and database servers, with different application branches for each of them as well, so local timezone is a good idea while speaking country-wide. For US servers, we are heading towards Central Time for all locations to match our main datacenter, since using different time zones for app servers and DB's is giving the developers a hard time.

  • 11
  • 1

The Yeller App recently published a blog post advising all sysadmins to use UTC. Here's an excerpt:

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.

Jokes aside, it's basically saying use only UTC means not bothering with Daylight Saving Time (DST), and the bugs that this brings about.

  • 1,253
  • 2
  • 11
  • 19