When looking at the valueOf value of a date object at the beggining of a year i expected to always receive zero seconds. The following code shows that until 1917 there was an offset of 54 seconds or 40 seconds in chrome. in IE i receive 0 seconds for all years.
Is there a reason for this? it seems to only happen in the last chrome version
for(var i=0; i<2020;i++)
if(!new Date(i,0,1).valueOf().toString().match("00000$"))
console.log({
y:i,
s: new Date(i,0,1).valueOf().toString().match(/(\d{2})\d{3}$/)[1]})
The date and time is broken up and printed in a way that we can understand as humans. JavaScript, however, understands the date based on a timestamp derived from Unix time, which is a value consisting of the number of milliseconds that have passed since midnight on January 1st, 1970.
What is this? The Date object in JavaScript does not store a time zone. It stores a timestamp that represents the number of milliseconds that have passed since midnight on January 1st, 1970.
JavaScript Stores Dates as Milliseconds JavaScript stores dates as number of milliseconds since January 01, 1970, 00:00:00 UTC (Universal Time Coordinated). Zero time is January 01, 1970 00:00:00 UTC.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With