Troubleshooting RTZ2 after Microsoft Update KB2998527
After the release of the above-mentioned update, many developers have encountered problems. At the moment, Chrome has somehow tried to fix the problem, but in IE10 (Document mode = "Standarts") everything works well, but in older browsers and IE compatibility modes, all work with dates has collapsed.
It so happened that due to technical limitations I have to support the work of the applications I develop in IE8-9-10 and Chrome. In addition, I use the momentjs library for working with dates.
Since the release date was just around the corner , then, having found a solution to the problem on the World Wide Web and not finding it, I decided that sooner or later the browser developers would solve this problem and I would not have to change anything. But the release is getting closer, but there was no solution, as it was.
')
And now it is time to solve this problem by yourself.
I will briefly describe the main problems in the form of a table (unexpected results arecrossed out ):
The first thing that came to mind was to modify the date work library (momentjs) to correctly compute time points and use it everywhere instead of the original Date object or find an alternative library. Looked at datejs, xdate, tzdata-javascript. But rewriting a lot of code for a "temporary" solution of problems seemed too time consuming. All the same, the hope that problems with the time zone will disappear with the following browser patches remains.
And then a bright thought came - to change the Date object. Let him handle problem dates and lead them to a single form independent of the browser. Those. new Date (2014, 0, 1) should always create a date 01/01/2014 00:00 UTC + 0400, then the momentjs.endOf ('year') will correctly count the end of the year.
How to achieve this?
The principle is the same - time in UTC + 0000 is continuous and time zone implementation errors do not affect it, therefore all date manipulations can be performed in UTC. And generally ignore work with the time zone in the browser once it works incorrectly. But this refinement should be transparent to the user (Web developer), i.e. he should still see the date in his local time zone.
Having studied the specification of the Date object , I developed the following method:
1. You must override the Date constructor so that it creates time in UTC.
Let's call the original Date object NativeDate, and the new (corrected) NewDate object.
Then NewDate (year, month, date) will actually execute the code NativeDate (NativeDate.UTC (year, month, date)).
2. The setTime, getTime and valueOf methods work with an offset, i.e., to describe schematically, NewDate.setTime (offset) performs NativeDate.setTime (offset + _nullOffset), and NewDate.getTf () and NewDate.valueOf () return NativeDate.getTime () -_ nullOffset. Where _nullOffset = -new NativeDate (0). GetTimezoneOffset () * 60000. This approach will ensure transparent operation with zero offset (new Date (0)).
3. Setters and getters for the Date, Day, FullYear, Hours, Milliseconds, Minutes, Month, Seconds properties of the NewDate object are referenced to setters and getters of similar properties with the UTC prefix of the NativeDate object. And setters and getters with a UTC prefix for NewDate will take into account the time zone.
After performing these steps, everything worked just fine.
However, to fully support the functionality of the original Date object, it was necessary to support all options for calling the Date constructor, as well as the Date.parse, Date.UTC, Date.now methods and all possible ways to serialize an object into a string.
It turned out something like this: rtz2fix .
I would be very happy if someone finds problems in this solution and informs me about them.
"Chrome that stole Christmas" ;
"New timezone - new problems . "
It so happened that due to technical limitations I have to support the work of the applications I develop in IE8-9-10 and Chrome. In addition, I use the momentjs library for working with dates.
Since the release date was just around the corner , then, having found a solution to the problem on the World Wide Web and not finding it, I decided that sooner or later the browser developers would solve this problem and I would not have to change anything. But the release is getting closer, but there was no solution, as it was.
')
And now it is time to solve this problem by yourself.
I will briefly describe the main problems in the form of a table (unexpected results are
| IE10 (IE8 standarts) | IE9 (all document modes) | IE10 (IE10 standarts) | Chrome 38.0.2125.122 m | |
|---|---|---|---|---|
| new Date (2014, 0, 1) | Wed Jan 1 00:00:00 UTC + 0300 2014 | Wed Jan 1 00:00:00 UTC + 0400 2014 | ||
| new Date (2015, 0, 7) | Wed Jan 7 00:00:00 UTC + 0300 2015 | |||
| moment (). startOf ('year') | Wed Jan 1 00:00:00 UTC + 0300 2014 | Wed Jan 1 00:00:00 UTC + 0400 2014 | ||
| moment (). endOf ('year') | Wed Dec 31 23:59:59 UTC + 0300 2014 | Wed Dec 31 23:59:59 UTC + 0300 2014 |
The first thing that came to mind was to modify the date work library (momentjs) to correctly compute time points and use it everywhere instead of the original Date object or find an alternative library. Looked at datejs, xdate, tzdata-javascript. But rewriting a lot of code for a "temporary" solution of problems seemed too time consuming. All the same, the hope that problems with the time zone will disappear with the following browser patches remains.
And then a bright thought came - to change the Date object. Let him handle problem dates and lead them to a single form independent of the browser. Those. new Date (2014, 0, 1) should always create a date 01/01/2014 00:00 UTC + 0400, then the momentjs.endOf ('year') will correctly count the end of the year.
How to achieve this?
The principle is the same - time in UTC + 0000 is continuous and time zone implementation errors do not affect it, therefore all date manipulations can be performed in UTC. And generally ignore work with the time zone in the browser once it works incorrectly. But this refinement should be transparent to the user (Web developer), i.e. he should still see the date in his local time zone.
Having studied the specification of the Date object , I developed the following method:
1. You must override the Date constructor so that it creates time in UTC.
Let's call the original Date object NativeDate, and the new (corrected) NewDate object.
Then NewDate (year, month, date) will actually execute the code NativeDate (NativeDate.UTC (year, month, date)).
2. The setTime, getTime and valueOf methods work with an offset, i.e., to describe schematically, NewDate.setTime (offset) performs NativeDate.setTime (offset + _nullOffset), and NewDate.getTf () and NewDate.valueOf () return NativeDate.getTime () -_ nullOffset. Where _nullOffset = -new NativeDate (0). GetTimezoneOffset () * 60000. This approach will ensure transparent operation with zero offset (new Date (0)).
3. Setters and getters for the Date, Day, FullYear, Hours, Milliseconds, Minutes, Month, Seconds properties of the NewDate object are referenced to setters and getters of similar properties with the UTC prefix of the NativeDate object. And setters and getters with a UTC prefix for NewDate will take into account the time zone.
After performing these steps, everything worked just fine.
However, to fully support the functionality of the original Date object, it was necessary to support all options for calling the Date constructor, as well as the Date.parse, Date.UTC, Date.now methods and all possible ways to serialize an object into a string.
It turned out something like this: rtz2fix .
I would be very happy if someone finds problems in this solution and informs me about them.
Related Links
"Chrome that stole Christmas" ;
"New timezone - new problems . "
Source: https://habr.com/ru/post/243685/
All Articles