I am trying to calculate the difference between two dates that are apart over 600 years.
I suspected it has something to do with leap seconds, but upon closer inspection, there is something even weirder going on. The extra 02:16 minutes are changed all at once between these two dates.
PS: My local timezone is UTC+1
new Date(1891, 8, 30)
// Wed Sep 30 1891 00:00:00 GMT+0057 (Central European Summer Time) <- this is weird
new Date(1891, 9, 1)
// Thu Oct 01 1891 00:02:16 GMT+0100 (Central European Summer Time) <- this is weird
new Date(1891, 9, 2)
// Fri Oct 02 1891 00:00:00 GMT+0100 (Central European Summer Time)
or
new Date(Date.UTC(1891, 8, 30, 23, 2, 15))
// Wed Sep 30 1891 23:59:59 GMT+0057 (Central European Summer Time)
new Date(Date.UTC(1891, 8, 30, 23, 2, 16))
// Thu Oct 01 1891 00:02:16 GMT+0100 (Central European Summer Time)
So ultimately I wanted to display n-th ongoing hour after d0 (below) and I was unexpectedly getting lagging hour that switched at 02:17 mark of a real hour.
I used something along these lines
let HR = 60 * 60 * 1000 // 3600000 ... one hour in milliseconds
let d0 = new Date(1358, 7, 14) // 14.8. 1358
let d1 = new Date(2011, 3, 17) // "today"
let dt = d1 - d0
let r = Math.ceil(dt / HR) // because I want to switch the hour as soon as first millisecond of that hour passes
But little did I know that dt / HR is actually not a whole hour but 5721214.962222222, whereas at this point of time I have already expected 5721215.
let something = dt % HR / 1000 / 60 // 57.73333333 minutes
In the end I worked around it with using Date.UTC and the respective getUTC... methods for all calculations, but I would still like to know more about this.
2
prologue (tl;dr, skip)
So apparently, only after spending a disproportionate amount of time on this, turns out I was using a wrong google search query GMT+0057, where UTC+0057 would give me a hit at the bottom of the google search page. Anyway, since 0057 doesn’t have enough results on google search and every country has its own weird Timezone Offset, I am still answering this so that when somebody else from my country stumbles upon this issue, the answer is readily available!
From the lone search result I would then get to this SO answer Parsing historical UTC date times gives an odd time zone shift
and eventually to this article on huffpost written by Brian Roemmele How, When, and Why Were Time Zones Created?
the answer
/edit This is even better, YouTube
The Problem with Time & Timezones – Computerphile
Anyway, in short: the apparent weirdness is because prior to certain dates (about 1900), which is different for each country, the countries or even cities would be using their own locally maintained times based on local solar noon, so offsets like +00:57, +10:04:52, +6:55:25 were pretty common. This has changed at some point in history of each country and the time had to shift several minutes at once or even whole days to accommodate for this.
For more information, read the huffpost article linked above and this excellent answer by Jon Skeet Browsers, time zones, Chrome 67 Error (historic timezone changes)
So now, retrospectively, it is nice that the timestamp honours these time shifts and JavaScript’s Date() object is kind enough to handle that for us with its various Date.UTC(), .getHours() or .getUTCHours() etc. methods.
Other resources:
Kdy začíná a končí letní čas @ kalendar.beda.cz
The Time Zone Database @ github
2