Date and Time Issues in JS

A rare programmer happens to avoid working with date and time. In general, date / time is a basic concept and in the majority of languages ​​there are built-in mechanisms for working with this type of data. It would seem that JS is not an exception, there is a built-in type Date, there are a bunch of functions in the prototype, however ...

Who is guilty

The first problem occurs when you need to set the date / time in a time zone different from UTC and from the local one. The Date constructor has no such parameter.

new Date(); new Date(value); new Date(dateString); new Date(year, month[, day[, hour[, minute[, second[, millisecond]]]]]); 

The only option where you can specify an offset relative to UTC is the third method. Calling the constructor in this format allows you to pass the offset as part of the string:
')

 new Date('Sun Feb 01 1998 00:00:00 GMT+0700') 

The string is adopted in RFC2822 format, which is very inconvenient and difficult to manually enter. Getting such a string from user input is almost impossible. I can not imagine a person who would agree to enter the date in this format.

Despite the fact that in the Date you can set all the parameters separately for the UTC timezone - this does not solve the problems - the timezone will remain local. But this is not the only problem.

Offset relative to UTC is not constant. This is a function of the date, time (well, or from the time stamp, if you like) and, again, the time zone. For example, for Moscow, the last time translation gives:

  new Date(2014, 9, 25, 0, 0, 0); // 26.10.2014, 21:00:00 GMT+3 new Date(2014, 9, 27, 0, 0, 0); // 25.10.2014, 22:00:00 GMT+4 

Thus, the constructor in the third version becomes almost useless since the offset needs to be known in advance. And it, as has been said, cannot be so simply obtained. The only library I came across that uses the Olson database for calculating shifts is timezone-JS . The problem with using this library is that the underlying libraries (date / time pickers) do not know anything about it and they actively use the standard Date inside. The rest of the libraries that work with the Date object do not explicitly refer to this database and do not receive updates from it. (Correct me in the comments.)

In a business application, time zones only make sense if a date and time are specified. For example, if a working day starts at 9:00, then you hardly expect your colleague from Vladivostok to start working at 15:00. Time zones should not be counted and in this case, the date should be displayed in UTC. However, in the case of regular events occurring at the same time in different time zones, the timezone is still needed. For example, your daily scrum begins at 10:00 for you and at 13:00 for Novosibirsk. By the way, this is precisely the difference between GMT and UTC. UTC is time without offset, and GMT is time with offset 0. Let me explain with an example:

 31.12.2014, 20:59:59 GMT        31.12.2014, 23:59:59 31.12.2014, 20:59:59 UTC        31.12.2014, 20:59:59 

Because of this, arithmetic basically confuses them. Unfortunately, it is confused with this parameter everywhere. The absence of a direct indication of the timezone in JS is treated as a local timezone, and the indication of UTC and GMT is equivalent.

Intl might help in a situation. Could, but not required. In particular, there is such a parameter timeZone, but, a little further the standard defines: The time zone to use. The only value implementations must recognize is "UTC". Currently, besides Chrome, more than one browser does not support arbitrary time zones.
With time ranges in JS everything is absolutely bad - there is nothing like this in the language. Do you want to do well - do it yourself.

What to do

• Option 1.

  Do not use arbitrary time zone. Option preferred and probably the most painless. That is, you only have local timezone and UTC. For these cases, all browsers seem to have everything, even if it is not very convenient. In addition, the timezone is set globally for the OS and changing it for a particular web application is non-kosher.
  

• Option 2.

  If arbitrary time zones are needed - do not use the time stamp. Totally. Keep your time in the savings bank in the RFC line indicating the time zone. I'm not sure that this will help defeat the timezone shifts in cross-browser understanding, but at least Chrome is aware of such shifts.

• Option 3.

  Situations are different and it happens that time is recorded in the database from any device. That is, in the form of a time stamp. There is nowhere to run, in order to display the time correctly, you need to know either the device timezone, or the user timezone, or both, and cheat all hand to hand shifts. Without the use of the base Olson is not enough.
  
  There must be a moral of this fable, but for now I have nothing more to add. In drafts of the ECMA standard, I don’t observe any progress, I guess they never will.