I've searched a lot, but couldn't find an explanation for this, in my opinion confusing behavior of getTime(). The documentation states:
getTime() always uses UTC for time representation. For example, a client browser in one timezone, getTime() will be the same as a client browser in any other timezone.
According to this statement, my understanding is, that e.g.
1. new Date (Date.UTC(2021,8,1)).getTime() // UTC Date 1.Sep.2021 00:00:00
2. new Date (2021,8,1).getTime() // Local (UTC+1) Date 1.Sep.2021 00:00:00
should deliver the same amount of milliseconds. But the results I'm getting are these:
1. 1630454400000
2. 1630447200000 // 1 hour (3600000 ms) missing
Question A: Physically the same amount of time has passed since 1.1.1970. Why are the results not equal (also daylight saving matters!) like they should, according to the docs?
Question B: If the behavior is correct, why is there one hour missing? Shouldn't there be one hour more? Logically UTC+1 is one hour ahead.
Ok, I found out what caused the confusion. Thanks for all your help! Especially to Chris G who pointed me in the right direction. Here is what screwed up my brain ;-)
All who didn't understand why there is an issue at all, were most likely looking at this from a regular webrowser user's point of view. In that scenario if a user in UTC+1 opens a website which calls getTime() at lets say 1. Sept. 2021 07:00:00, that would result in this:
now Date ( 2021, 8, 1, 7, 0, 0 ).getTime()
Now if a second user does the same at exactly the same moment in UTC+0, this would result in:
now Date ( 2021, 8, 1, 6, 0, 0 ).getTime()
Then of course we are getting the same results! My problem was that I assumed that calling:
now Date ( 2021, 8, 1, 7, 0, 0 ).getTime()
in different time zones should give the same result. Which is NOT the case! Now you may ask why someone would need this. The reason is simple. I'm developing a little Gantt tool in Electron and there I need to compare/subtract dates. Of course I don't need the above to be true (deliver the same values), but I came accross this problem, because I was not getting divisable numbers of milliseconds when subtracting dates by converting them to ms with getTime(). I was expecting that according to the doc, which says that getTime() will give the same value in every time zone, to get an absolute value which is not influenced by time zones or daylight saving, for calculation. Thus I expected that e.g.:
now Date(2021,4,1,0,0,0).getTime() - now Date(2021,11,1,0,0,0).getTime()
Should give a number of milliseconds, which should be perfectly divisiable by 86400000 (one day). But that was not the case. The reason is that the second date is 1h behind because of daylight saving!
Conclusion
The statement in the doc is true when looking at the same point in time (e.g. UTC+0 06:00 and UTC+1 07:00), but not when looking at the same number of hours (e.g. UTC+0 07:00 and UTC+1 07:00). That was what confused me. Maybe this explanation helps others as well.