If you have a server hosting Jira and Confluence, what timezone do you set it to? UTC, or the timezone your users are in?

There is a serverfault discussion about this, and on the face of it, the question is why wouldn't  you use UTC? Timezones are messy, ugly, human things. Why complicate your nice clean server with them?

In this post I'll outline why I think you should set your server to the timezone of the bulk of your users, rather than nice clean UTC, and specifically why, if you find yourself setting the -Duser.timezone=...  parameter, you're probably making life harder for yourself than necessary.

Keeping the same timezone within a server

First, I think we can all agree, files on the same server should all have the same time zone.

There are at least 3 log-generating things you'll be concerned with:

• The app server (Jira, Confluence), and their log files (atlassian-jira.log, atlassian-confluence.log)
• The web server (Apache, nginx) and their log files (access.log)
• The operating system and its logs (/var/log/*) and persistent performance stats (e.g. /var/log/atop/*)

For your debugging sanity, it is essential that all these log files have the same timezone.

The web server and OS logs are all in the OS timezone, obviously.

How about app server logs, atlassian-jira.log and atlassian-confluence.log? Well, app server log timestamps will also be in the OS timezone, unless you've told Java otherwise, by explicitly setting -Duser.timezone .

If you've set -Duser.timezone , you can no longer correlate datestamps between atlassian-jira.log, access.log and the rest of the system.

So don't do that. Leave Java in the same timezone as your OS.

Why not UTC?

There are two arguments against setting your server timezone to UTC.

The argument from ease-of-debugging

Users report problems relative to their timezone. Screenshots might be saved with timestamped filenames. "Things got really slow around 4pm" they'll say, and off you go to find what was happening on the server at 4pm.

Perhaps my tooling is a bit primitive, but I don't know an easy way to convert timestamps from UTC to that of an arbitrary user, on the fly. If the log's timezone is that of the user, life just is just easier.

The argument from Confluence developer laziness

"But", our administrator says, "I want UTC on the server for <insert sane, excellent reasons>, and I use <insert names of tool that let me view logs in any timezone, which I shall share with you in the comments>. Why can't the OS and Java be set to UTC, and the apps be told only to display dates in a specific format?"

The answer is that this would be possible, had not the Confluence developers failed to implement a default user timezone setting ( ).

To review, the timezone users see in Jira and Confluence comes from one of various levels:

User preference	Users can explicitly set their timezone in their profile: Jira Confluence
Default user preference	If your user preference isn't set, the default user preference will be in effect. Jira Jira conveniently lets you edit the default user timezone in General Configuration: Confluence Confluence does not let you edit the default timezone ( ). Instead you have to resort to editing XML files inside jars.
Java user.timezone	The default user timezone preference inherits its value from the Java user.timezone Java property.  You can set this user.timezone Java flag in bin/setenv.sh, e.g. to -Duser.timezone=America/Los_Angeles .
OS timezone	Finally, Java sets its user.timezone property default to the operating system's timezone: $ cat /etc/timezone Australia/Sydney

If Confluence allowed a default user timezone preference to be set (like Jira), then it wouldn't matter what your OS or Java timezone was set to. Set them to UTC or whatever you like.

But sadly, because the default user timezone must equal the timezone of atlassian-confluence.log , and (for your sanity) you want atlassian-confluence.log  in the same timezone as your OS, they must all be set to the default timezone of your users. Since you're doing this for Confluence, you might as well do it for Jira too.