How Should We Manage Time Zones?

Welcome to one of the hardest problems in non-computational programming — properly representing dates and times to end users.

First, let’s clarify a few general concepts.

UTC — The World’s Time Standard

Coordinated Universal Time (UTC) is the basis for civil time today. It’s a standard used to set all time zones around the world.

UTC is a time standard, not a time zone.

The local time anywhere in the world can be obtained by adding or subtracting an offset from UTC.

What Is a Time Zone?

The term time zone can be used to describe several different things, but mostly it refers to the local time of a region or a country.

The numbers on the bottom indicate the offsets. GMT has an offset of 0. (Image source: University of Hawaii )

GMT (Greenwich Mean Time) is a time zone and UTC is a time standard.

The time in the time zones to the left of the prime meridian can be obtained by subtracting the offset from UTC. Similarly, the time in the time zones to the right can be obtained by adding the offset to UTC.

The UNIX Timestamp: How Computers Store Time Information

The UNIX timestamp is a way to track time as a running total of seconds.

// Create a new JavaScript Date object based on the timestamp
let unix_timestamp = Date.now();

// multiplied by 1000 so that the argument is in milliseconds, not seconds.
let date = new Date(unix_timestamp * 1000);

// example outputs
console.log(unix_timestamp); // 1671544611402
console.log(date); // Sat Feb 21 54939 06:36:42 GMT+0300 (GMT+03:00)

This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the UNIX timestamp is merely the number of seconds between a particular date and the Unix Epoch. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.

Time zones affected by boundaries (Time zone selection interface in Ubuntu)

So, what are our options in front-end — back-end communications?

Sending Converted Values to Front-end

• We already store the user’s time zone in the database in this option. So, the back-end sends all date/time values already converted to the user’s time zone based on the saved time zone data.
• The advantage of this approach is that the front-end doesn’t have to do any work.

Sending UTC Values to Front-end

• Send UTC values to the front-end and let the front-end handle the work of displaying date/time values based on the user’s time zone from the user’s information request or just from the browser's local settings.
• The advantage of this approach is that the front-end captures the user’s time zone from the user’s information request payload and can be more precise.

Answering This Question Help Us Weigh The Cost Vs The Benefit

How much does the time zone matter to our users for different conditions?

For example;

• Is it a push service with delivery time where time is crucial?
• Or is it a campaign editing/deleting where time is more disposable?

So, the easiest way to deal with date/time information depends on our application requirements.

Overview of Approaches

• The general rule is ‘Always store date time in UTC on the server side’ and ‘Always send date times as UTC’ and only convert with user time zone on the presentation layer.
• Make sure the date-time is in UTC when we’re handling it with our back-end code.
• Date time data in formatted strings are for display.
• Stay consistent with the format of date times in the front-end by using a standard, such as ISO 8601 or timestamp maybe. When front-end send requests to the back-end, send the date time in ISO 8601/timestamp format so that the back-end can easily convert it to the corresponding UTC date time.
• Single source of “now”. If we need the current time on the client, just get the user’s time zone from our user’s information request and calculate the Now date with it.
• In code base related to all these time zone functionalities, there should be helper functions where the source of accuracy is the only one.
• All these written back-end and front-end codes should have the user’s time zone-specific unit tests.
• There exist libraries in all major web development languages and frameworks for better handling of date times. These libraries make it much easier to convert or format to standards. We should choose and use the most common and most useful of these types of libraries.

Is Storing Date Times in UTC Always Good Practice?

Storing date times in UTC is good practice unless you have to store future date times, in which case you need to save the “clock time” and the time zone, in case that time zone changes DST (Daylight Saving Time) in the future. Kind of edge-cases but countries change their DST dates all the time and sometimes drop in/out completely.

For instance, what will happen if you schedule a push service at 12:00 but the push takes place after the change to daylight saving time? UTC does not keep any information on whether DST was active when the push was stored. The user sends a push at 9 am in the summer, and then in the winter, the sent time shows 8 am, because the calculation back from UTC depends on when you look at the date time, not on when the date time was recorded.

Conclusion

Working with human times correctly is complicated, unintuitive, and needs a lot of careful attention to detail to get right. Further, some of the oft-given advice, like always working in UTC, can cause problems of its own.

If you liked this article, you may be interested in Introduction to Micro-Frontends or Axios vs fetch() articles.