Tested the issue on windows 7 using chrome M58 #58.0.3029.110 and issue is reproduced.

Same behavior is seen in firefox browser also and attached screenshot for reference.

@mak07020702--- Could you please confirm if this has worked before or it is a feature request.

Thanks!

Deleted: 722738.PNG 335 KB

	722738.PNG 335 KB View Download

This isn't a duplicate of the bug that Hannes marked, as that bug is about the string-to-date parser, which isn't invoked here.

I can't reproduce the issue on Linux, in either Chrome or Firefox--I get the correct answer, 240, for both, in both browsers (as well as in ChakraCore and JSC).

I wonder if the issue is with the Windows timezone database. It looks like both V8 and SpiderMonkey make the same system calls, localtime_s/localtime_r (depending on the OS), to get at the timezone offset for the Date class.

No action to be done here without more feedback from reporter.

@hdodda, I apologize for the late response.

I tried with an old version and the issue seems to reproduce. See the attached screen shot. Japanese letters mean Paraguay standard time.

Please note that whether the issue reproduces depends on the OS clock. When the OS clock is set to year 2015, the issue does not reproduce. Same behavior is seen in the latest version of Chrome as well.

Deleted: screenshot.PNG 35.5 KB

	screenshot.PNG 35.5 KB View Download

jshin, can you take a look into this?

I suspect that this bug can be used to argue for enabling 'icu_time_zone' (what's the flag name exactly, I forgot) Dan added recently.  There are other bugs as well. 

I'm not on Windows. 

mak07020702,   can you post the results of the following two lines? Thanks 

new Date(Date.UTC(118, 2, 31, 12)).toLocaleString('en-US', 
      {timeZoneName: 'long', year: 'numeric', month: 'short',
        day: 'numeric', hour: '2-digit', minute: '2-digit'});


new Date(Date.UTC(118, 1, 1, 12)).toLocaleString('en-US', 
      {timeZoneName: 'long', year: 'numeric', month: 'short',
        day: 'numeric', hour: '2-digit', minute: '2-digit'});

On Windows 7, I changed the tiemzone to America/Asuncion. 

I confirmed that Date.toString() is indeed broken on Windows with the timezone set to America/Asuncion. Or, toString() has a different idea of when DST ends from toLocaleString() in 2018 in America/Asuncion. 

> d2018mar31 = new Date(Date.UTC(2018,2,31,12))
Sat Mar 31 2018 09:00:00 GMT-0300 (Atlantic Daylight Time)

> d2018mar31 = new Date(Date.UTC(2018,2,31,12))
Sat Mar 31 2018 09:00:00 GMT-0300 (Atlantic Daylight Time)

"Mar 31, 2018, 8:00 AM Paraguay Standard Time"

---------------

new Date(Date.UTC(2018,2,31,12))
Sat Mar 31 2018 09:00:00 GMT-0300 (Atlantic Daylight Time)
new Date(Date.UTC(2018,3,21,12))
Sat Apr 21 2018 08:00:00 GMT-0400 (Atlantic Standard Time)
new Date(Date.UTC(2018,5,21,12))
Thu Jun 21 2018 08:00:00 GMT-0400 (Atlantic Standard Time)

------------------------

 IE 11 agrees with ICU ( used by Date.toLocaleString()):

> (new Date(Date.UTC(2018,2,31,12))).toString()
"Sat Mar 31 2018 08:00:00 GMT-0400 (Paraguay Standard Time)"

> "Mar 31, 2018, 8:00 AM Paraguay Standard Time"

The above is the output of 

d2018mar31.toLocaleString('en-US', 
      {timeZoneName: 'long', year: 'numeric', month: 'short',
        day: 'numeric', hour: '2-digit', minute: '2-digit'});

This was fixed but later the fix was reverted. (see https://chromium-review.googlesource.com/713404 ). 

From comment 8:

> I wonder if the issue is with the Windows timezone database. It looks like both V8 and SpiderMonkey make the same system calls, localtime_s/localtime_r (depending on the OS), to get at the timezone offset for the Date class.


I agree with Dan here. However, comment 15 (setting the system time to year 2015 fixed the problem) is strange. 

Anyway, turning on --icu-timezone-data should fix this issue. 

Because the standard timezone offset has remained the same (4 hours behind UTC) while the transition date changed over time (early April to late March), this issue wouldn't require fixing  bug v8:3547 . 

See https://bugs.chromium.org/p/chromium/issues/detail?id=283647#c17 if you want to get a fix right away.