There is a mistake in the month index (December should be 11, i.e. new Date(2010, 11, 14)), but it reproduces for 11 as well.

The same happens on the Mac OS. See attached.

Deleted: ^96777C92EB664C95D7552B5CFDB25F8E9E424AF9D4A423D6CA^pimgpsh_fullsize_distr.png 317 KB

	^96777C92EB664C95D7552B5CFDB25F8E9E424AF9D4A423D6CA^pimgpsh_fullsize_distr.png 317 KB View Download

bogachev.aleksey@ Thanks for the issue

Unable to reproduce this issue on Windows 10 and Mac OS 10.12.6 on the reported version 62.0.3202.94, latest Canary 65.0.3300.0 and Stable 63.0.3239.108 by following the below steps.

1. Changed the timezone to (UTC+03:00) Moscow, St. Petersburg, Volgograd at System settings ->Date&Time -> Change the timezone. (Using this timezone as Moscow Standard Time is currently being Used in Belarus)
2. Launched Chrome and opened Devtools -> Console.
3. Executed new Intl.DateTimeFormat('en-US', { day: 'numeric'}).format(new Date(2010, 11, 14));  and new Intl.DateTimeFormat('en-US', { day: 'numeric'}).format(new Date(2011, 11, 14)); and can see the output as 14.

Attached is the screen shot for reference.

Request you to please update Chrome to the latest version and retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks...

Deleted: 796583.png 106 KB

	796583.png 106 KB View Download

It looks like the issue reproduces on the (UTC+03:00) Minsk timezone only. 
I switched to the  (UTC+03:00) Moscow, St. Petersburg, Volgograd at System settings and the output was correct in both cases ("14").

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on reported version 62.0.3202.94, on latest stable 63.0.3239.108 , latest beta 64.0.3282.39 and on latest canary 65.0.3301.0 using Ubuntu 14.04, Windows 10 and Mac 10.13.1 with timezone as (UTC+03:00) Minsk
This issue is seen from M50[50.0.2661.0]. Hence considering this issue as Non-Regression and marking as Untriaged.

Note: Issue is seen firefox as well.

Can repro on Minsk, Belarus timezone on Canary on MacOS.

jshin, can you take a look?

This is because Date constructor in v8 interprets 2010-12-14 with the current timezone offset of Europe/Minsk (UTC+0300) instead of the then-effective timezone offset of Europe/Minsk (UTC+0200) while Intl API uses the then-effective timezone offset (UTC+0200). 

With TZ=Europe/Minsk, |new Date(2010,11,14)| creates 20101213T2100 (UTC) = 20101214T0000 (UTC + 3; Minsk time in 2011) = 20101213T2300 (UTC+2 ; Minsk time in 2010). 

Run the following with d8 and TZ=Europe/Minsk. 

--------cut--------here-----------------

d2010dec14 = new Date(2010,11,14);
d2010dec14T11am = new Date(2010,11,14,11)
d2011dec14=new Date(2011,11,14)
d2011dec14T11am=new Date(2011,11,14,11)

var dfloc= new Intl.DateTimeFormat('en-US', {timeZoneName: 'short', weekday: 'short', year: 'numeric', month: 'numeric', day: 'numeric', hour: 'numeric', minute: 'numeric'})
var dfutc= new Intl.DateTimeFormat('en-US', {timeZoneName: 'short', weekday: 'short', timeZone: 'UTC',year: 'numeric', month: 'numeric', day: 'numeric', hour: 'numeric', minute: 'numeric'})

const dates = [d2010dec14, d2010dec14T11am, d2011dec14, d2011dec14T11am];
dates.forEach(function(d) {
  print(d + ' (Date)');
  print (dfloc.format(d) + ' (Intl(localtime))');
  print (dfutc.format(d) + ' (Intl(UTC))');
});
-----------cut------here--------------------

$ TZ=Europe/Minsk out/rel/d8  minsk.js 
Tue Dec 14 2010 00:00:00 GMT+0300 (EET) (Date)
Mon, 12/13/2010, 11:00 PM GMT+2 (Intl(localtime))
Mon, 12/13/2010, 9:00 PM UTC (Intl(UTC))
Tue Dec 14 2010 11:00:00 GMT+0300 (EET) (Date)
Tue, 12/14/2010, 10:00 AM GMT+2 (Intl(localtime))
Tue, 12/14/2010, 8:00 AM UTC (Intl(UTC))
Wed Dec 14 2011 00:00:00 GMT+0300 (EET) (Date)
Wed, 12/14/2011, 12:00 AM GMT+3 (Intl(localtime))
Tue, 12/13/2011, 9:00 PM UTC (Intl(UTC))
Wed Dec 14 2011 11:00:00 GMT+0300 (EET) (Date)
Wed, 12/14/2011, 11:00 AM GMT+3 (Intl(localtime))
Wed, 12/14/2011, 8:00 AM UTC (Intl(UTC))

Note that Europe/Minsk in Dec 2010 was UTC+2, but Date ctor uses UTC+3 (the current timezone offset) while Intl.DTF uses UTC+2. 


Europe/Moscow has a similar issue. In Dec 2010, it's fine(UTC+3 is correct), but in Dec 2011, its offset was UTC+4, but Date ctro assumes that it's UTC+3 throughout (because the current offset in effect is UTC+3). 

 TZ=Europe/Moscow out/rel/d8  minsk.js 
Tue Dec 14 2010 00:00:00 GMT+0300 (MSK) (Date)
Tue, 12/14/2010, 12:00 AM GMT+3 (Intl(localtime))
Mon, 12/13/2010, 9:00 PM UTC (Intl(UTC))
Tue Dec 14 2010 11:00:00 GMT+0300 (MSK) (Date)
Tue, 12/14/2010, 11:00 AM GMT+3 (Intl(localtime))
Tue, 12/14/2010, 8:00 AM UTC (Intl(UTC))
Wed Dec 14 2011 00:00:00 GMT+0300 (MSK) (Date)
Wed, 12/14/2011, 1:00 AM GMT+4 (Intl(localtime))
Tue, 12/13/2011, 9:00 PM UTC (Intl(UTC))
Wed Dec 14 2011 11:00:00 GMT+0300 (MSK) (Date)
Wed, 12/14/2011, 12:00 PM GMT+4 (Intl(localtime))
Wed, 12/14/2011, 8:00 AM UTC (Intl(UTC))

Using '--icu-timezone-data' is supposed to take care of it, but it does not unfortunately in this case. I'll look into that. 

  bug v8:6031  is about icu-timezone-data. 

A work-around in the meantime is to specify hour far away from the midnight (say, noon) so that it's not affected by timezone offset changes when printing date. 

This can be fixed only after both  bug v8:6031  and  bug v8:3547  are resolved.