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.
Debian/Ubuntu
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):
MySQL
To configure MySQL to use UTC:
[mysqld_safe]
timezone = UTC
For more information see this StackOverflow
post
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.zone
config.time_zone = 'Central Time (US & Canada)`
Details found
here