It may seem logical to run your server or application in your local time zone. However, this can lead to unintended complexities.
In this article, we'll outline why it is best practice to use Coordinated Universal Time (UTC) as the time zone for your servers and applications, helping you:
We'll also provide some links, and examples, to help you manage your server and application's time zone configurations.
Let's imagine you have multiple servers across the world; one is in New York (Eastern Time - ET), one is in London (Greenwich Meantime - GMT), and the other is in Tokyo (Japan Standard Time - JST).
UTC is a constant, precise global standard. Regional time zones are not standards; they may change throughout the year and over time.
Scheduling tasks and managing data across different time zones can introduce complexity and error. Adopting UTC helps avoid unnecessary complexity and offsets errors, for clear, consistent, and accurate operations.
When coordinating tasks across systems, specifying the time in UTC eliminates ambiguity and minimizes the risk of misunderstandings and human error.
For example, let's say you ask your team to schedule a job that syncs data from your three servers. The job should run at 24:00, midnight. If you don't use UTC, this simple request can cause confusion:
UTC is explicit. No matter where your servers or developers are, the UTC will always be constant.
Requesting a job to run at "24:00 UTC" ensures a consistent reference point regardless of the location of servers, services, or team members.
Alongside the obvious benefits of avoiding scheduling conflicts and confusion, using UTC ensures:
Some regions use Daylight Savings Time (DST) to adjust for changes in sunlight hours during different seasons. DST involves moving clocks forward from Standard Time (STD) to extend daylight hours.
For example, New York and London observe DST, but the starting dates for DST vary:
The dates for transitioning between STD and DST are not fixed; for example, in the UK, it's the last Sunday in March, while it's the second Sunday of March in New York.
This can lead to confusion and human error, because tasks that were once synced suddenly fall out of sync as the server switches between STD and DST.
Most hosting providers, like Heroku, Digital Ocean, and AWS, will use UTC by default but offer the ability to modify your server time zone.
If you are unsure what time zone your server is using you can use the timedatectl
or ls -l /etc/localtime
commands. For more detailed instructions on managing your server's default time zone, you can consult your hosting provider's documentation:
How you can manage your application's time zone varies depending on your application's language/framework and configuration.
Elixir uses Calendar.UTCOnlyTimeZoneDatabase
by default. You can learn more in Elixir School's Date and Time lesson.
Node.js will use your OS time zone per default, so if your Node.js server is you can also configure your Node.js app's timezone via the TZ
environment variable:
# .env file TZ=UTC
# .env file TZ=UTC
Depending on your Python application's setup, there are different ways of managing its time zone.
You can use the TZ
environment variable:
import os os.environ['TZ'] = 'UTC'
import os os.environ['TZ'] = 'UTC'
For example, in Django applications, you can use the TIME_ZONE
attribute in settings.py
:
# settings.py TIME_ZONE = 'UTC'
# settings.py TIME_ZONE = 'UTC'
You can configure the global time zone using Python's pytz library:
import pytz timezone = pytz.timezone('UTC')
import pytz timezone = pytz.timezone('UTC')
Ruby will use your OS time zone by default. The TZ
environment variable can be used to define a time zone that differs from the time zone of the OS the application is running on, for example:
ENV["TZ"] = "UTC" => "UTC" Time.now => 2024-03-25 13:54:56.290081 +0000 ENV["TZ"] = "Asia/Tokyo" => "Asia/Tokyo" Time.now => 2024-03-25 22:56:18.914783 +0900
ENV["TZ"] = "UTC" => "UTC" Time.now => 2024-03-25 13:54:56.290081 +0000 ENV["TZ"] = "Asia/Tokyo" => "Asia/Tokyo" Time.now => 2024-03-25 22:56:18.914783 +0900
If you supply the TZ
variable with a non-valid time zone, the UTC will be assigned instead:
ENV["TZ"] = "AppSignal" => "AppSignal" Time.zone.now => "UTC"
ENV["TZ"] = "AppSignal" => "AppSignal" Time.zone.now => "UTC"
UTC is the default time zone for Rails applications. In Rails, the application time zone can be defined via the time_zone
config variable in config/application.rb
.
To change your Ruby application to UTC, remove the time_zone
config option or set it to UTC
:
# config/application.rb config.time_zone = "UTC"
# config/application.rb config.time_zone = "UTC"
AppSignal offers a 30-day free trial, no credit card is required. All features are available in all plans. Start monitoring your application in just a few clicks!