Time Zones and moment isBetween('yesterday', 'today')
- Origin of Time Zones
- The Law and Time Zones
- Browser's Time Zone Support and Its Limitations
- Time Zone Data and Its Problems
- Front End's Solution
- Goodbye moment.js
For Koreans, Summer Time is not a very familiar concept. For those who live in the effective ranges of Summer Time, there are days when a day is 25 hours or 23 hours long. We usually take 24-hour days as the norm, but why do some countries fixate on such fluctuation?
Time zone is an idea to represent different times all around the world. Browsers, in order to account for these time zones, offer multiple solutions. However, these solutions are not enough to satiate the needs for time zone management of the web services' users.
This article serves to illustrate why we need time zones in the first place, its history, and how to properly support time zones in the front end. Time zone is a challenge that every developer will face at some point in one's career. Let's take this opportunity to fully understand the it.
Origin on Time Zones
Time on Earth is absolute. While this feels like we're about to discuss the Time Stone from the Avengers franchise, but we just have to know that there is one time. However, times are different depending on whether you are in Korea, United States, or in the United Kingdom. Why is that? I explained the concept of the time zone to my eleven-year-old son as such. "Son, it's because day and night are different depending on where you are on the planet. Would it not be weird if someone in the UK had to go to work at nine in the morning but someone in Korea had to go to work at six in the afternoon? So, people created different time zones to standardize the time the nine in the morning (when the Sun is actually shining) so people can go to work."
Time zones are results of significant consideration of the Earth's rotation created to artificially correct the difference in day and night around the world. If someone in the UK wants to go to work at nine in the morning and someone in Korea wants to go to work at nine in the morning, the person in Korea can just go to work nine hours earlier than the person in the UK. This is why the Korean Standard Time is also referred to as +09:00. Laws have declared the Greenwich Time (GMT) the standard, +00:00, since 1675, so the history is long.
The Law and Time Zones
There is a catch. Time zones are not set in stone. Since time zones were created to artificially correct the differences by location, time zones have changed throughout history according to the geographical attributes. Why would people change the time zones instead of having it standardized, for example +1 hour or -6 hours by longitude? There doesn't seem to be much need for change.
If you take a close look at time zones, there is not a single place where the time zone is the same just because they have the same longitude. Even Seoul and Gangneung can have different time zones. Therefore, people have meddled with the time zones according to the country or a certain part of the country. However, time zones went through even more altercations due to history, political, or economic reasons.
For example, Netherlands used to use incredibly specific offset of +00:19:32.13. However, they later changed to using a more standardized +01:00.
Korea is thin widthwise. There is not much of a need to specify intricate time zones. Then, how about a country like China that is wide? Does China also use one time zone like Korea, or does it have multiple time zones in different provinces? The answer is "they use a single time zone." China maintains a single time zone despite its wide area. Therefore, you can see the Sun come up at ten in the morning in some western parts of China.
On the other hand, United States, a country that is also wide, uses multiple time zones for different states. We can observe that the time zones in the western parts of the United States and time zones in the eastern parts of the United States differ by three hours in the same country.
(Source: Namu Wiki Time Zones)
The country of Samoa used to use -10:00 time zone until they decided to change the time zone to +14:00 to minimize the loss created by the time difference with Australia and New Zealand, their trading partners. Due to this incident, people who had their birthdays on December 30th in Samoa losing their birthdays in the year 2011.
Time Zones and Offset
Time zones represent the differences in times in different countries and locations. This time zone is also a way to represent the absolute time offset with respect to the longitude. Therefore, time zones and offsets act as aliases. Furthermore, a time zone can have more than one offsets, and the most iconic example is the Summer Time.
Summer Time
Places that are affected by Summer Time have two different offsets. In the Winter, the western parts of the United States use the Pacific Standard Time (PST) and from March to November, Summer Time kicks in, and they use the Pacific Daylight Time (PDT). In other words, the western parts of the United States, from March to November, use an offset that is an hour less than what they have been using during the Winter. The reason that they adopt Summer Time is to correct for the longer days so that the day and night can be differentiated appropriately.
If you're someone like me who has lived in Korea for my entire life and have never been to any study abroad programs, Summer Time is not a familiar concept. It's natural to hear things like "that place is ahead of Korea by so-and-so hours," or "it's night here, and it's morning in Korea," but it's just more complicating to find out that there is another twist in the Winter because of the Summer Time.
Browser's Time Zone Support and Its Limitations
Then how should browsers, JavaScript, to be more specific, support different time zones? As you know, JavaScript has a Date type to represent dates. Browsers implement the ECMAScript's specs and the specs specify the definition of time zones and Summer Times. However, the issue is the fact that the included definitions are terse and ambiguous. The content basically states that browsers try their best to be accurate, so I assume that the browser vendors must have scratched their heads as well. This is why the Date features works differently for different browsers. Furthermore, ECMAScript does not even specify making changes in the time zone. Perhaps this is why browsers and Node.js require that you follow the time zone configured in the OS. In other words, time zones for browsers from computers in Korea will be Asia/Seoul, and this creates more difficulties when having to use the Date object to represent different time zones in different countries. If you had to change the browser time zone settings to that of another country, you would have to change it in the OS settings.
Time Zone Data and Its Problems
Previously I made a point of noting that time zones can have multiple offsets and can be switched around as needed. Contrarily, Korea's Asia/Seoul time zone and Japan's Asia/Tokyo time zone have the same offset of +09:00 but with different names. There are more situations where it is difficult to determine the offsets programmatically according to the longitude given the geopolitical trends.
Therefore, time zones must manage a database of change history. The most credible database right now is the IANA Time Zone Database. While Windows maintains its own database, Java's VM uses and regularly updates the IANA database.
This exact issue is why it is difficult to implement different time zones with JavaScript. Given ECMAScript's ambiguous specifications and the fact that browsers do not have these databases, we cannot simply change the time zone using the Date type.
Front End's Solution
Then how do we resolve this issue? There are two main ways. One, implement a built-in time zone database in the webpage, and two, use the Intl.DateTimeFormat appended to the ECMAScript to address these types of problems.
Built-In Time Zone Database
If we had to support a range of browsers that include older browsers, our services must be able to be accessible even in browsers that do not have the Intl.DateTimeFormat support. In this case, there is no other way but to include a database file that documents all of the changes in the time zones. For example, if we had to find what 17:00 on 3rd of July 2020 is in different time zones, we would have to address the database to tell the time difference. We would have to consult the database for every offset operation including whether the time zone is affected by Summer Time and whether the Summer Time is happening right now or not.
moment.js defines the offset according to the following json database.
{
name : 'America/Los_Angeles', // the unique identifier
abbrs : ['PDT', 'PST'], // the abbreviations
untils : [1414918800000, 1425808800000], // the timestamps in milliseconds
offsets : [420, 480] // the offsets in minutes
}Source: Zone object - https://momentjs.com/timezone/docs/
moment.js and js-joda
The among the libraries that I've looked at, moment.js and js-joda have time zone databases. Since databases are heavy in memory, they have opted to support both reduced version that contains the most recent ten years’ worth of data or the entire database. Aside from the fact that such databases are heavy because the entire database must be included in full, there does not seem to be a better way for older browsers.
JavaScript does not offer a way to convert time zones using the Date and the Intl.DateTimeFormat, but moment.js and js-joda can be utilized to support older browsers and implement the time zones directly.
Goodbye moment.js
Several weeks ago, moment.js, loved by many developers, announced that they would not publish additional builds and just work on maintenance.. You may be surprised by this, as there is a lot of people who love and use the library. However, I believe that it is the right move, as I see support for Internet Explorer stopping within a year. In order for the web to move progressively towards cutting out legacies and in the direction of standardization, such decisions by impactful libraries are significant. This is the correct path to building a standardized web that offers the same service without discrimination.
ECMAScript's Internationalization Features and Specs
ECMA-402 specifies Intl.DateTimeFormat for internationalization as well as the feature to use the IANA database. This feature supports the appropriate date and time for different languages. However, this feature does not yet return a specific time zone's offsets directly. You must configure the time zone and then return the resulting string in the given language, and the offset is included in the resulting string. So, in order to get the offset, you must parse the returned string.
const date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
const options = {
timeZone: 'America/Los_Angeles',
timeStyle: 'long'
};
console.log(new Intl.DateTimeFormat('ko-KR', options).format(date));
// 오후 7시 0분 0초 GMT-8The Intl.DateTimeFormat has the option to specify the name of the time zone in the IANA database. Then, the format() function returns the string (GMT-8) and this can be parsed to obtain the offset. It can be a hassle to implement it manually, and perhaps this is why we use libraries. Libraries like dayjs, luxon, date-fns, and more offer features where the Intl can be processed to obtain useful information about date and time zones, conveniently. Such libraries can take the place of moment.js in its vacancy.
Closing Words
Time zones and Summer Time have always been a mountain of issues and considerations for front end development. moment.js, with its time zone database, has lowered the implementation complexity and has been an effective solution. Up until now, it was just moment.js, straight up. However, with moment.js's brazen decision, I believe that we are one step closer to eradicating the legacy issues and to a more standardized web.
Time zones can be a weird concept for someone who, like myself, lived only in one place. However, understanding time zones, why the time zones cannot be programmatically encoded, and why databases are used for time zones, can be useful in creating a service that is used worldwide. I hope this article has helped.