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:

• ✅ Ensure scalability
• ✅ Avoid scheduling issues
• ✅ Keep server interactions in sync
• ✅ Simplify debugging

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 time standard, not a time zone

UTC is a constant, precise global standard. Regional time zones are not standards; they may change throughout the year and over time.

Utilizing UTC for time synchronization

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.

Clear scheduling with UTC

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:

• Developers may not know which time zone to use: New York, London, or Japan.
• If the jobs are set to sync at 24:00 local time, the sync jobs will run asynchronously.
• Even if you request "24:00 JST", there is room for human error in calculating what time that is in New York and London.

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.

Ensure consistency with UTC

Alongside the obvious benefits of avoiding scheduling conflicts and confusion, using UTC ensures:

• Consistent data interpretation: Timestamps recorded in UTC can be easily correlated, ensuring that critical information (such as application, server, or database logs) remains synchronized across systems. This streamlines debugging and analysis.
• Seamless integration with external services: Many external services and APIs use UTC. Adopting UTC simplifies third-party integrations and removes the need for datetime conversion.
• An offsetting overhead is avoided: Using UTC reduces the need for complex time zone conversions, removing the risk of variations in data handling and processing.

Avoid Daylight Saving Time

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:

• New York switches to DST on March 10
• London switches to DST on March 31
• Japan does not observe DST

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.

How to switch to UTC

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 to change the time zone in Digital Ocean
• How to change the time zone in AWS
• How to change the time zone in Heroku

How do I manage my application's time zone?

How you can manage your application's time zone varies depending on your application's language/framework and configuration.

Elixir

Elixir uses Calendar.UTCOnlyTimeZoneDatabase by default. You can learn more in Elixir School's Date and Time lesson.

Node.js

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

Python

Depending on your Python application's setup, there are different ways of managing its time zone.

Environment Variable

You can use the TZ environment variable:

import os
os.environ['TZ'] = 'UTC'

Django

For example, in Django applications, you can use the TIME_ZONE attribute in settings.py:

# settings.py
TIME_ZONE = 'UTC'

pytz library

You can configure the global time zone using Python's pytz library:

import pytz
 
timezone = pytz.timezone('UTC')

Ruby

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

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"

Rails

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"