3

Starting Chrome 67 (full version is 67.0.3396.87), I am experiencing weird behaviour with creation of a new Date object. Smallest reproducible case, goes something like:

    <html>
    <body>    
    <script>    alert(new Date(-62135596800000));        </script>
    </body>
    </html>

On Firefox 60.0.2 the alert message is:

Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)

On Internet Explorer 11 and Edge 41.16299.461.0, the alert message is same as Firefox:

Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)

However, on Chrome 67 I see:

Sun Dec 31 0000 23:58:45 GMT-0001 (Greenwich Mean Time)

Edit: JsFiddle

Edit2 Turns out it's nothing to do with Microsoft's library.

Evdzhan Mustafa
  • 3,645
  • 1
  • 24
  • 40
  • 2
    FWIW I could replicate this (I've been looking at the orange "update" arrow in Chrome all day, this seemed a good time to hit it) - [quick JSFiddle](http://jsfiddle.net/teu0a84g/) before I updated, in 66 I saw Jan 01, after update to 67 I get Dec 31 etc. – James Thorpe Jun 13 '18 at 15:27
  • @JamesThorpe Can I include your fiddle in my question? – Evdzhan Mustafa Jun 13 '18 at 15:29
  • 1
    Sure, no problems – James Thorpe Jun 13 '18 at 15:29
  • 3
    FYI you also see the same thing if you just put `new Date(-62135596800000)` in the console, so looks like it's actually the date handling in Chrome that's changed somewhere rather than anything MS script specific. – James Thorpe Jun 13 '18 at 15:30
  • Possible duplicate of [How do you create a JavaScript Date object with a set timezone without using a string representation](https://stackoverflow.com/questions/439630/how-do-you-create-a-javascript-date-object-with-a-set-timezone-without-using-a-s) – t1gor Jun 13 '18 at 15:32
  • Your `alert()` call implicitly converts the date instance to a string. If you use `alert(model.SampleDayTime.toUTCString())` instead, then you explicitly request that the browser give you UTC time instead of the default local time. – Pointy Jun 13 '18 at 15:36
  • @Pointy what timezone is 1 minute and 15 seconds off? – Matti Price Jun 13 '18 at 15:38
  • @MattiPrice I agree that something odd is going on. – Pointy Jun 13 '18 at 15:41
  • The MS script ... is it purposed to run on browser? – Teemu Jun 13 '18 at 15:43
  • 2
    [A bug report has already been filed for this](https://bugs.chromium.org/p/chromium/issues/detail?id=852298). – James Thorpe Jun 13 '18 at 15:48
  • @JamesThorpe Will have to follow the bug report. I wonder if it is something to do with BigInt -> https://developers.google.com/web/updates/2018/05/nic67#bigint? – Evdzhan Mustafa Jun 13 '18 at 15:50
  • Perhaps, but you'd hope not as the number you're using is still well above `Number.MIN_SAFE_INTEGER`! – James Thorpe Jun 13 '18 at 15:51
  • @JamesThorpe I don't think it's actually a bug. See my answer below – Matti Price Jun 13 '18 at 15:59
  • @MattiPrice Good catch, if they've started using more accurate historical data that may well explain it. I hate timezones :P – James Thorpe Jun 13 '18 at 16:02
  • [Another issue where it's being discussed](https://bugs.chromium.org/p/chromium/issues/detail?id=849724). – James Thorpe Jun 13 '18 at 16:06
  • [And another](https://bugs.chromium.org/p/chromium/issues/detail?id=849404) where it's specifically been marked as wontfix. – James Thorpe Jun 13 '18 at 16:08
  • 3
    @JamesThorpe I think that saying needs to be updated.. "There are 3 things that are difficult in computer science. Naming things, Cache invalidation, Timezones, and off by one errors" – Matti Price Jun 13 '18 at 16:17

2 Answers2

5

Depending on the response to that bug report, I think this is actually due to Chrome possibly including IANA timezone information. Browsers, time zones, Chrome 67 Error

For example, when I run that fiddle, I get Sun Dec 31 0000 18:09:24 GMT-0550 (Central Standard Time) which corresponds to the IANA entry Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24.

So this is a "feature" not a bug I think. They are using the more "accurate" historical time offsets instead of current day time offsets for historical dates.

You can view the data here : https://github.com/eggert/tz just look for your appropriate world location file and try and avoid all the commented out lines unless you are morbidly curious about the history of your time zones.

What you can do to "fix" it so it display more or less correctly is to call .toUTCString() on the Date object which will force it to UTC time and display Mon, 01 Jan 0001 00:00:00 GMT as @Pointy pointed out in the comments on the initial question.

Matti Price
  • 3,351
  • 15
  • 28
  • @Pointy this mean's that your bit about `.toUTCString()` actually does fix it since it knows how to convert from some weird fraction of an hour offset! – Matti Price Jun 13 '18 at 16:20
  • Well the point of my comment was that relying on client time zone in general was probably not a good idea for the OP. – Pointy Jun 13 '18 at 17:01
  • One thing not mentioned much in this question and its comments+answers is the fact that the OP is working with a really weird timestamp for some reason. – Pointy Jun 13 '18 at 17:01
  • @Pointy definitely true, and would actually solve the OP's problem. I'm going to edit that in if that's cool with you. – Matti Price Jun 13 '18 at 17:02
-2

Your code, as long as MS's one, doesn't know anything about the timezone, so I assume Chrome takes the default one.

I guess it should be better if you create your date as below:

const date = new Date(Date.UTC(year, month, day, hour, minute, second));
t1gor
  • 1,244
  • 12
  • 25
  • 1
    There's no timezone in an epochal timestamp like -62135596800000. That's always interpreted as an offset from a fixed point in time (January 1, 1970, 00:00:00) – Pointy Jun 13 '18 at 15:33
  • Fair enough. Point noted and sorry for the confusion. – t1gor Jun 14 '18 at 07:46