If you’re wondering how or on what basis were time zones curated, this solely depends on the information derived from the Earth’s rotation on its axis. Every sixty minutes, the Earth turns on its axis by around fifteen degrees and completes a 360-degree spin after twenty-four hours. Taking this into consideration, these insights were used to divide the Earth into twenty-four slots or time zones. As a result, you can find every time zone to be separated by fifteen degrees of longitude.
Now that you better understand how time zones were created, let’s shed some light on a few essential terminologies before discussing the different approaches used to calculate time zones today.
Important Time Zone Terminologies To Familiarise Yourself With
Epoch time, the universal date on whose basis all other dates are calculated, is a method of defining a specific point in time. On the first of January, 1970, the Unix epoch was 00:00:00 UTC (an arbitrary date). Because Unix time is nonlinear, a leap second has the same Epoch time as the second before or after.
Every day has exactly 86400 seconds, without any seconds added or deducted due to negative or positive leap seconds. However, Unix time is not considered to be a fair representation of UTC because of the handling of leap seconds.
Everything you need to know about Zone Offset
The difference in minutes and hours between UTC and a specific time zone is known as zone offset. The zone offset can be specified in ISO 8601 as a date or time value. It can be a figure “+” or “-” from UTC or Z for UTC. The value 08:00-08:00, for example, denotes 8:00 a.m. in a time zone running 8 hours behind UTC, which corresponds to 16:00Z. The value 08:00+08:00 is the inverse increment or midnight.
What is Daylight Saving Time?
Daylight Saving Time, commonly referred to as summer time, is a clock-advancement mechanism that extends daylight hours during traditional waking hours throughout the summer months. In the Northern Hemisphere, clocks normally advance one hour in late March or early April and then revert one hour in late September or early October.
Three Different Approaches To Handling Time Zones Today
Whenever the date and time are transferred from the client to the server, they are usually sent with the offset. However, while storing the data in the database, the server converts the data into a string storing only the date and time, not the offset. The ignored offset might not seem like a big issue unless the server deals with international clients or a country with multiple time zones.
Thus it might not be the correct date when the time is sent to a different timezone due to the missing offset. In order to provide a solution to this issue, we have listed three approaches one could proceed with when handling time zones.
Approach 1: Storing time as a string with offset in the database
With this approach, the time sent from the client is converted into a new date object by the server and stored in the database with the offset as a string. When a client asks for the time, the server sends the converted time to the client with the offset. Storing the time as a string with the offset in the database is an approach that’s usually not preferred by many comparatively.
Approach 2: Storing time as numbers in the database
In the second approach, the time sent from the client is converted into epoch time by the server and stored in the database. When a client asks for the time, the epoch time is sent, so the client converts it into the regular date and time according to their time zones.
This approach can handle time with millisecond precision easily. Although the limit of int relational databases is usually 32 bits, meaning dates will go back to negatives after 2038-01-09 03:14:07 UTC. Storing time as numbers in the database is an approach that is generally used in logging and analytics cases.
Approach 3: Storing UTC dates in the database
The third approach, i.e., storing UTC dates in the database, doesn’t depend on the time but on the server. The time sent from the client is converted into UTC by the server and stored in the database. When clients ask for the time, they receive the UTC, which they then convert into a regular date and time according to their time zones.
By storing UTC dates in the database, you can store dates without worrying about limits (9999-12-31 23:59:59Z). Also, despite taking more memory than an integer, this approach tends to represent actual dates better. And is additionally used to handle real-world events-based applications like contest start times, and a multitude of others.
Final Verdict
We have discussed everything you need to know about time zones and a few approaches to handle the primary problem statement outlined above. In order to handle time zones and understand them better, you need to be familiar with terminologies like epoch and offset due to their relevance to the concept.
The three primary approaches to handling time zones include: Storing time as a string with offset in the database, storing time as numbers in the database, and storing UTC dates in the database. After taking into consideration each of their limitations and benefits, you can proceed with whichever approach seems fit per your database and server.
