2

If I pass the unix milliseconds timestamp value for 1/1/1753 (at midnight) (-6847786800000) to the JavaScript Date() constructor in Chrome, the Date Chrome gives me looks really weird. I get other weirdness when I use the Date() constructor that takes seven parameters. Examples are below.

Chrome:  new Date(-6847786800000): Mon Jan 01 1753 00:03:58 GMT-0456 (Eastern Standard Time)
Firefox: new Date(-6847786800000): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)

Note how Chrome made the time 3:58 and the timezone GMT-0456 (the weird timezone appears to be about the same amount as the weird time (4 minutes).)

Chrome:  new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0456 (Eastern Standard Time)
Firefox: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)

Note how Chrome gives me 0:00 for the time, but still has that GMT-0456 timezone.

Playing around with various dates, this odd behavior seems to start with dates before 1884 - not sure of the exact date. 1/1/1884 acts as you would expect, but 1/1/1883 gets this "off by 3:58" behavior.

Is this a bug or am I missing something?

I tested this on: Chrome 67.0.3396.99 (Official Build) (64-bit); Firefox 61.0 (64-bit); IE 11 and Edge 42.17134.1.0 give the same results as Firefox

UPDATE

This does not look like a duplicate of Browsers, time zones, Chrome 67 Error to me. That question is talking about timezones being different. It uses 1900 as an example. I'm talking about the time being different. And it only affects stuff before 1884. It does not affect 1900 dates.

Why would changing the timezone change the actual time? I'm not a timezone wizard but that still seems wrong to me.

UPDATE

So yeah, probably a duplicate in some sense. Don't know for sure if Chrome changed it's behavior with this. But it does come down to the fact that right now Chrome will see old unix timestamps, before 11/18/1883 at 12:03:58 PM, as different points in time than other browsers. So watch out if you need to work with timestamps for old dates. I switched away from using timestamps to avoid this issue.

Tom Winter
  • 1,813
  • 3
  • 18
  • 23
  • Note this question talking about weird issues with Chrome and Angular around 1884. https://stackoverflow.com/questions/40005884/dates-prior-to-jan-2-1884-show-as-a-day-prior-in-angular2-date-pipe – Tom Winter Jul 03 '18 at 17:02
  • Can anyone direct me to the source code for Chrome's Date constructors? – Tom Winter Jul 03 '18 at 17:02
  • Nothing to do with Angular. Chrome does that on purpose to be spec compliant. Extending modern time zones backwards into the past doesn't make sense (says somebody). – Pointy Jul 03 '18 at 17:04
  • [Reference](https://chromium-review.googlesource.com/c/v8/v8/+/572148) – Pointy Jul 03 '18 at 17:06
  • I figured it had nothing to do with Angular itself. But the 1884 part seemed important, as I explained in my edit. – Tom Winter Jul 03 '18 at 17:23
  • I'm pretty sure you're seeing the same behavior. There are several other duplicates out there, and several Chromium bugs logged (and closed). The time changes because the time *zone* is weird. If you explicitly ask for the UTC time, you'll see that that's *not* weird. – Pointy Jul 03 '18 at 17:31
  • Can you point me to some of the Chromium bugs,out of curiosity. Thanks! – Tom Winter Jul 03 '18 at 18:09
  • 2
    Tracking this down has been hard for me. ;-) After trial and error I found that 1883-11-18 12:03:57.999 is the magical time where this stuff starts to happen. A quick Google and this is when Railway Standard Time started. So this date does actually mean something. See bottom of https://railroad.lindahall.org/essays/time-standardization.html – Tom Winter Jul 03 '18 at 18:11
  • 1
    It's some kind of IANA standard thing. It sort-of makes sense, though if you regularly deal with really old timestamps it's probably a massive pain. – Pointy Jul 03 '18 at 18:12

0 Answers0