1426412 - Intl.DateTimeFormat.format seems to be work incorrectly

Status: RESOLVED DUPLICATE of bug 1330307

(Core :: JavaScript: Internationalization API, defect, P5)

Description

[Alexey]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

Make two calls to Intl.DateTimeFormat.format functions with two dates that have the only one difference in year:

new Intl.DateTimeFormat('en-US', { day: 'numeric'}).format(new Date(2010, 12, 14)); 


new Intl.DateTimeFormat('en-US', { day: 'numeric'}).format(new Date(2011, 12, 14)); 


The timezone of my PC is GMT+0300 (Belarus Standard Time).

The angular 4 uses Intl.DateTimeFormat under the hood in  the date pipe. Thus, it is highly important to fix this issue asap.
 


Actual results:

"13"
"14"


Expected results:

It should print "14" in both cases

Comment 1

[Alexey]

The FF version is 57.0.2 (64bit) Funnelcake Win64 Q2 2017 mozialla 105 - 1.0, 
OS windows 10

Comment 2

[:Gijs (he/him)]

Not a security issue that needs to stay hidden.

Comment 3

[Michael Kohler [:mkohler]]

I can't reproduce this on Mac OS, neither with Release nor Nightly using the same timezone. Maybe this is Windows only?

Comment 4

[Alexey]

This issue is also reproduced on the Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=796583

The weird thing is that it works fine in IE/edge :)

Comment 5

[André Bargull [:anba]]

Windows always uses the current time zone rules for |localtime_s|, so if there have been any time zone rules changes, like the change to abandon DST in Belarus in 2011 Mar 27, past dates can be incorrect (bug 1330307, bug 1335818). Last I checked, Chrome/V8 was also using |localtime_s| which explains why this bug can also be reproduced in Chrome. Edge/ChakraCore uses a different Windows API (GetTimeZoneInformationForYear?) instead of the Windows POSIX layer, so it seems they don't get this |localtime_s| limitation. 
The long-term plan should be to use a different library to compute all time zone information (bug 1346211), so we no longer have to workaround OS-dependent issues and can provide the same data on all platforms.

Comment 6

[Nicolas B. Pierron [:nbp]]

André, should this bug be a duplicate of one of the previous you mentioned?

Comment 7

[André Bargull [:anba]]

Yes, we can dup this to bug 1330307.

As for a workaround, using noon instead of midnight as suggested by :jungshik in https://bugs.chromium.org/p/chromium/issues/detail?id=796583#c13 sounds reasonable.