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..."

Configuration

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.

MySQL

PostgreSQL

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

Oracle

Good luck, hire a DBA.

Django

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'

Rails

UTC out of the box.

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

About the Author

Ross is a 17 year veteran of the software industry with experience
spanning low-level signal processing, web and mobile user interfaces,
high-scale distributed web services, infrastructure, and networking. He
has made extensive contributions to open source highlighted by his time
as a primary maintainer of Gtk2-Perl and author of
requests-futures
and python-asynchttp
libraries.
(more)