3

The following was observed on:

  • Chrome 57.0.2987.133 (64-bit)
  • Firefox 52.0.2 (32 bits)
  • Node.js 6.9.1

The following was not observed on:

  • Edge 38.14393.1066.0

I observed a strange behavior in some browsers when formatting some dates that are older than a specific date.

The following was done in the Paris timezone, during daylight saving time (in april):

new Intl.DateTimeFormat('fr').format(new Date(1975, 9, 26)); // returns "25/10/1975"
new Intl.DateTimeFormat('fr').format(new Date(1975, 9, 27)); // returns "27/10/1975"

As you can see, the first line returns an incorrect value. This is also the case with all dates older than 1975-09-26.

What's interesting is that 1975-09-26 is a dailight savings change date in France. But why is there an issue with that specific year? Daylight savings were in effect before 1975.

We got the same issue if we look into the time:

new Intl.DateTimeFormat('fr', { hour: 'numeric', minute: 'numeric' }).format(new Date(1975, 9, 26, 2, 0)); // returns "01:00"
new Intl.DateTimeFormat('fr', { hour: 'numeric', minute: 'numeric' }).format(new Date(1975, 9, 26, 3, 0)); // returns "03:00"

This shouldn't happen. The formatted hour should be the one returned by Date.getHours().

new Date(1975, 9, 26, 2, 0).getHours() // returns 2

As this is observed on both Firefox and Chrome, I'm wondering if they are using the same date formatting engine, and whether there is a bug in that engine.

Also, I am wondering if that can be reproduced on another timezone with daylight savings.

Anyone has any insight?

Edit:

Possible related bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=680114 https://bugzilla.mozilla.org/show_bug.cgi?id=1330307

Edit 2:

Actually not always the same behavior with older dates.

This one is interesting:

new Intl.DateTimeFormat('fr', { hour: 'numeric', minute: 'numeric' }).format(new Date(1900, 2, 26, 2, 0)); // returns 00:09

It's explained by the small time difference back then and the bug mentionned in Matt's answer.

Edit 3:

FYI, the French legislation says to switch to/from daylight savings time on the last Sunday of march and october.

jlowcs
  • 1,933
  • 1
  • 10
  • 16

1 Answers1

0

You have hit upon a bug in the Windows localtime_s function. It only takes into account the current DST rule, and assumes that same rule has always been in effect - even if there is better data available.

This bug is reported several times as various browser issues. You hit upon two of them already. You can see another effect of it in this StackOverflow Q&A.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Is that only on Windows 10, or older versions as well ? – jlowcs Apr 17 '17 at 16:52
  • Also, it's pretty strange that Edge ends up being the only non-buggy one. – jlowcs Apr 17 '17 at 16:58
  • Older also. Edge doesn't use that particular API. There are better ones available. Chrome and Firefox need to use those to fix their bugs. Anyway, we're getting deeper than is useful for StackOverflow. :) – Matt Johnson-Pint Apr 17 '17 at 18:29
  • 1
    This is not *necessarily* a bug. An implementation was required to make its "best effort" using "best available information" as of [*ECMAScript 2015*](http://www.ecma-international.org/ecma-262/6.0/index.html#sec-daylight-saving-time-adjustment). Prior to that, they were only required to apply current rules [*as if they had always existed*](http://www.ecma-international.org/ecma-262/5.1/index.html#sec-15.9.1.8). So it's only a bug in implementations that claim conformance with ECMAScript 2015 or later. – RobG Apr 17 '17 at 22:52
  • 1
    @MattJohnson I just tested my code on Linux (Ubuntu) and MacOS 10.12.3, and I'm having the same issues, so it seems like it's not only a Windows issue. – jlowcs Apr 18 '17 at 09:55
  • 1
    @RobG still, it's a bit problematic to have a date wrongly displayed to the user. Angular 2+, for instance, uses Intl.DatTimeFormat for its date "pipe", so that can become pretty problematic pretty fast. – jlowcs Apr 18 '17 at 09:57
  • @jlowcs—I agree that it's not reliable, just quibbling over what it's called in some implementations. :-) – RobG Apr 18 '17 at 20:25