Once upon a time in UTC

Centuries ago, people measured time by the sun's position. Today, we rely on atomic clocks and software algorithms. But as timekeeping evolved, so did the complications—none more confusing than the humble yet baffling timezones. Today, let's talk about it.

Timezones are super weird and complicated to handle in software systems like calendars scheduling apps, international travel booking websites, global collaboration tools, etc which are used by users across the globe.

Just think about it - a single point in time can be represented differently across various regions worldwide, leading to countless coordination challenges and potential bugs in the systems.

I like to start from the basics so let's talk about some history things.

How it all started

Time zones were created in the 19th century to standardize timekeeping, primarily due to the expansion of railroads and communication systems. Before this, local solar time was used, leading to confusion. Sir Sandford Fleming proposed a 24-hour global time system in 1879, and the concept was adopted during the International Meridian Conference of 1884, where Greenwich, England was decided as the Prime Meridian. This formed the basis of the modern time zone system, dividing the world into 24 zones of 15 degrees each as the earth rotates at that rate.

Alright, that’s enough of the Wikipedia stuff.

Understanding timezone and related concepts

Timezone is the region on Earth which has a uniform standard time. The starting point for time zones is the Prime Meridian, which is 0 degrees longitude and runs through Greenwich, London. As you move eastward or westward from the Prime Meridian, time zones offset increase or decrease by one hour per longitude line respectively. The timezone offset is the difference between the UTC and local time.

image source: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

The timezone offset for regions in the country is decided based on various factors such as distance from the nearest longitude line, geopolitical needs, etc. Most of the countries follow multiple time zones to save electricity and make better use of daylight.

Some countries, such as India and China, have chosen to adopt a single time zone across the entire territory, despite spanning multiple theoretical time zones.

DST - Daylight Saving Time

DST is a practice of adjusting clocks forward and backwards according to the time of the year to extend daylight. The main goal is to make better use of natural light and save energy as discussed previously.

For example, In the United States, DST starts on the second Sunday in March (clocks move forward 1 hour) and ends on the first Sunday in November (clocks move back 1 hour).

In some cases, only certain parts of a state observe DST while others do not. This typically happens due to local decisions, unique geographical factors, or cultural preferences. In such a scenario, different regions within the same state may follow different time rules, creating a complex timekeeping system.

The Time Zone Database

To keep track of all of these timezones, their offsets and DST changes we have a Time zone database which keeps a record of historical changes and current timezones. It is maintained by the Internet Assigned Numbers Authority (IANA).

Time zones, their rules, offsets, and observation (or non-observation) of DST are controlled by a variety of international agreements, as well as national, regional, sub-national, and local governments. This can mean that neighbouring areas that might otherwise share a UTC offset, even those with similar latitude can have differing rules. Sometimes local authorities will change the boundaries of a zone or the offset used. Or they can make one-time changes to accommodate special events. The time zone database tracks past changes so that applications can accurately compute wall time for past and future events.

Because there are many governing bodies acting independently, the time zone database is not stabilised.

Working with Timezones

As an engineer building applications which cater the users across the globe, understanding practices for dealing with dates & time is necessary.

Saving timestamps in UTC and converting them to the user's local timezone when displaying is generally a safe approach. This method ensures consistency across different timezones and simplifies many time-related calculations. However, for more complex scenarios such as future events or recurring schedules, additional considerations may be necessary.

If you are building something like a global collaboration tool or future event management software, understanding and deciding when to use instants (UTC timestamp) and when to use wall-clock time (local time) is one of the most important calls you’ll have to make. In some cases, the answer should be obvious: if you need to store when something was created, that’s an instant. Instants are definitely more common in backend systems, especially for anything that happened in the past. But there will be other times when the answer isn’t clear, and you’ll have to make a design decision.

For future events, saving in timezone with additional information such as current offset is critical for handling unexpected DST changes.

Best Practices for dealing with dates and times

1. Store dates and times in UTC and do business logic in the same time zone.

2. Generate and handle UTC dates and times on the server side wherever possible.

3. Use a standardized format such as ISO 8601, Unix Epoch Timestamp to avoid ambiguity when accepting date and time values

This was just an introduction to timezones, I have not talked about some of the important and very interesting concepts such as problems due to unexpected DST rule changes, the significance of leap seconds, some of the problems such as the Year 2038 Problem, etc. There is a lot to explore and discuss about this topic. Stay tuned for a detailed article.

Thank you for reading :)