weird seconds offset in js date object in chrome

This is Not a BUG..

As @Krzysztof pointed out Chrome has implemented a new spec for timezone offset calculation following the merge of Make LocalTZA take 't' and 'isUTC' and drop DSTA(t) to Ecma 262. So now the time-zone conversion does not work by just backward interval of seconds, it is calculated as what local time was being observed in a specific region.

Explanation:

I am from a wonderful little country called Bangladesh of South-Asia which follows BST(Bangladesh Standard Time +0600 GMT), which was not always exactly 6 hours ahead of GMT. As JavaScript date takes in local time when I print the start time of this year in GMT I get:

new Date(2018, 0, 1).toUTCString()// "Sun, 31 Dec 2017 18:00:00 GMT"

In 2009 one hour day-light saving was observed in Bangladesh from 19 June to 31 December. So if I print the first day of December 2009 I get:

new Date(2009, 11, 1).toUTCString()// "Mon, 30 Nov 2009 17:00:00 GMT"

You can see the day-light saving is now reflected in the date now, which is not visible in my nodeJS console. There was also changes in local time in 1941-1942 as shown below and can be seen on timeanddate.com:

All of the changes are reflected in Chrome now:

new Date(1941, 6, 1).toUTCString()// "Mon, 30 Jun 1941 18:06:40 GMT"new Date(1941, 11, 1).toUTCString()// "Sun, 30 Nov 1941 17:30:00 GMT"new Date(1942, 7, 1).toUTCString()// "Fri, 31 Jul 1942 18:30:00 GMT"new Date(1942, 11, 1).toUTCString()// "Mon, 30 Nov 1942 17:30:00 GMT"

So now if I pick any date before 1941 keeping in mind my local time is 6 hours ahead I see an offset of 6 minutes 40 seconds. It will vary depending on the time-zone for the back dates due to the recent update of Chrome, or specifically saying the update of ECMAScript(JavaScript).

This may not be 100% the solution of the problem, but one can get the "jitter" introduced by chrome by casting it to UTC and back, then compensate with a new new Date(oldDate.getTime() + jitter).

        // Compensates for google chrome 67+ issue with very old dates.        // We should skip this test if any other browser.        $getJitter: function (d) {            var utcDate = new Date(Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCMilliseconds())),                jitter = 0;            // As we're setting UTC date, the non-UTC year could be            // shifted one ahead or behind, so set the utc full            // year to ensure compliance.            utcDate.setUTCFullYear(d.getUTCFullYear());            if (d.getFullYear() != utcDate.getFullYear() ||                d.getMonth() != utcDate.getMonth() ||                d.getDate() != utcDate.getDate() ||                d.getHours() != utcDate.getHours() ||                d.getMinutes() != utcDate.getMinutes() ||                d.getMilliseconds() != utcDate.getMilliseconds()) {                // infers the "jitter" introduced during the conversion to compensate in the                // actual value of ticks                jitter = d.getTime() - utcDate.getTime()            }            return jitter;        }

This "jitter" pretty much depends on the time zone. For Brazil I'm getting a 28 seconds noise (so it gets back to like, 12:00:00 AM > 23:59:32 PM the previous day.

For Brazil the issue happens down to 1913. This coincides with the time we got our daylight saving times and time zone to -3:00 from -3:06, according to the time changes over years at https://www.timeanddate.com/time/zone/brazil/sao-paulo.

With the above code you can explore the broken dates with this loop:

for (var i=1900; i < 2020; i++) { for (var j=0; j < 12; j++) {  var dt = new Date(i, j, 1);  var jitter = System.DateTime.$getJitter(dt);  if (jitter != 0) {   console.log("broken: " + i + ", " + j + ", jitter: " + (jitter/1000) + "s: " + dt.toString());  } }}