XOR Media

UTC is the Only Real Timezone

If you’re storing or transmitting time information in any way shape or form (web-services, databases, queues, NoSQL, caches, log files, or just plain txt files) the safest and thus best thing to do is to use UTC (Coordinated Universal Time) everywhere.

Yes you have to do math, but you get used to it faster than you’d think and tools like this cheat sheet (coming soon) can help.

There are a couple main and several smaller, but still important, reasons to go this route the first of which is if you end up with users in multiple timezones you’ll be able to cleanly and easily show things to them in their preferred time with relative ease.

When times are stored in UTC the conversion to a user’s time is a simple addition/subtraction (which you should let well established libraries do for you.) If however, you store times in another timezone converting is much more complex, worse case being one that observes Daylight Savings Time and one that doesn’t. Furthermore this translation should wait until the last possible stage. Generally in web-based applications this means the template rendering, but could possibly be in JavaScript.

Another reason is that you may end up with servers in data centers which span timezones. Whether it’s because you’ve outgrown your data center capacity or the more likely need to geo locate servers closer to users, as soon as you have hosts that span timezones UTC will make it much easier to track events that span them (log file times should be in UTC.)

What’s even more likely than having boxes in multiple timezones is that you’ll have people who aren’t in the same timezone as the servers, perhaps everyone. It can help to speak in UTC in communications between international teams (so long as they’re all engineers they can likely cope with it.)

Finally the biggie, you’ll have far fewer bugs if you keep things in UTC through as much of the stack as possible. Do anything else and you’ll run in to frequent problems that require traipsing up and down your software and systems stack to suss out. “Uhhhh the database was returning PST, the app server was configured in EST, and the user is in Belgium…”


Note that the most important part is that the underlying system is running in UTC, without that everything else will be painful. Once you have the system in UTC it’s time to get your software stack using it as well. The good news is that most things default to using the system timezone, but for more detail take a look through the following examples.


System-wide (should do this for any server):

echo "UTC" | sudo tee /etc/timezone
sudo dpkg-reconfigure --frontend noninteractive tzdata

For more information see Ubuntu Time

If you just want to run a command in a timezone other than the one configured on the local system (in this case blank means UTC and we’ll run the date command):

TZ= date


To configure MySQL to use UTC:

timezone = UTC

For more information see this StackOverflow post


Short answer is that it stores things in UTC internally. The long answer can be found here


Good luck, hire a DBA.


If you’re using 1.4 and above, you probably want to include pytz in your requirements and then you can configure the following in your settings.

USE_TZ = True
# if all of your users are in a single timezone you can set it here and the
# rendering will do the conversion for you, if you have users in multiple
# timezones it's best to leave this as UTC and use django's
# timezone.activate to set a timezone on a per-request basis.
TIME_ZONE = 'America/Los_Angeles'


UTC out of the box.

# set a site-wide timezone which can be overridden per-request by setting
# Time.zone
config.time_zone = 'Central Time (US & Canada)`

Details found here