Different date parse result in chrome and firefox.

[heroboy]

in xlsx.js:

var basedate = new Date(1899, 11, 30, 0, 0, 0); // 2209161600000
var dnthresh = basedate.getTime() + (new Date().getTimezoneOffset() - basedate.getTimezoneOffset()) * 60000;
function numdate(v) {
	var out = new Date();
	out.setTime(v * 24 * 60 * 60 * 1000 + dnthresh);
	return out;
}

The dnthresh is different in firefox and chrome.
Conside the code:

d=new Date(1899, 11, 30, 0, 0, 0),[(d.getTime()),d.getTimezoneOffset(),d.toISOString(),d.toLocaleString(),d.toString()]

• result in chrome:

[-2209190743000, -485, "1899-12-29T15:54:17.000Z", "1899/12/30 上午12:00:00", "Sat Dec 30 1899 00:00:00 GMT+0805 (中国标准时间)"]

• result in firefox:

[ -2209190743000, -485.71666666666664, "1899-12-29T15:54:17.000Z", "1899/12/30 上午12:00:00", "Sat Dec 30 1899 00:00:00 GMT+0805 (中国标准时间)" ]

The firefox result is correct. For gmt 805, I think firefox's timezoneoffset is correct.

[SheetJSDev]

Can you run Intl.DateTimeFormat().resolvedOptions() in both chrome console and ff console and share the result? Specifically interested in locale and timeZone keys. Here's from my local machine in Chrome:

[heroboy]

This is from my home pc. The OS setting is different from above.
firefox:

d=new Date(1899, 11, 30, 0, 0, 0),[(d.getTime()),d.getTimezoneOffset(),d.toISOString(),d.toLocaleString(),d.toString()]
Array(5) [ -2209189002000, -456.7, "1899-12-29T16:23:18.000Z", "12/30/1899, 12:00:00 AM", "Sat Dec 30 1899 00:00:00 GMT+0736 (Hong Kong Standard Time)" ]

Intl.DateTimeFormat().resolvedOptions()
Object { locale: "en-US", calendar: "gregory", numberingSystem: "latn", timeZone: "Asia/Hong_Kong", year: "numeric", month: "numeric", day: "numeric" }

chrome:

d=new Date(1899, 11, 30, 0, 0, 0),[(d.getTime()),d.getTimezoneOffset(),d.toISOString(),d.toLocaleString(),d.toString()]
(5) [-2209189002000, -456, "1899-12-29T16:23:18.000Z", "1899/12/30 上午12:00:00", "Sat Dec 30 1899 00:00:00 GMT+0736 (香港标准时间)"]0: -22091890020001: -4562: "1899-12-29T16:23:18.000Z"3: "1899/12/30 上午12:00:00"4: "Sat Dec 30 1899 00:00:00 GMT+0736 (香港标准时间)"length: 5__proto__: Array(0)
Intl.DateTimeFormat().resolvedOptions()
{locale: "zh-CN", calendar: "gregory", numberingSystem: "latn", timeZone: "Asia/Hong_Kong", year: "numeric", …}

[heroboy]

The result is wired. Because I installed the English window 10. And install and use the Chinese UI language, and set locale to Chinese PRC. And the installed language order is (Chinese,Hong Kong,English). But the timezone setting is always be "Beijing UTC+8"

[heroboy]

And the edge(not the new chrome edge) result:

[-2209190400000, -480, "1899-12-29T16:00:00.000Z", "1899/12/29 下午11:36:42", "Sat Dec 30 1899 00:00:00 GMT+0800 (中国标准时间)"]
{
calendar: "gregory"
day: "numeric"
locale: "zh-CN"
month: "numeric"
numberingSystem: "latn"
timeZone: "Asia/Hong_Kong"
year: "numeric"
}

[heroboy]

@SheetJSDev

https://github.com/exceljs/exceljs/blob/1cc3c1863872353a3ba58db323f6f56fb13b76a7/lib/utils/utils.js#L56-L59

I think this code may correct.

[SheetJSDev]

Excel interprets date/time codes based on the timezone of the computer. 12:00 AM in an XLSX or XLS or XLSB file will be 12:00 AM if you open the file in New York or Los Angeles or Hong Kong or Beijing or Seoul. If no corrections are made for the timezone, then the results are likely incorrect outside of UTC.

A cursory reading of exceljs/exceljs#486 suggests they push the problem of localization to the library user, which doesn't really address the underlying problem.

[SheetJSDev]

After some digging, here's the conclusion:

HK offset had a seconds component (according to https://www.timeanddate.com/time/zone/hong-kong/hong-kong and the IANA tz database it was +7:36:42 during 1899).

The weird offset is technically correct. Chrome and nodejs appear to be rounding the offset, hence the difference in values between FF and Chrome.

We've raised the issue with NodeJS nodejs/node#33306

As for how we fix this library, we're closing this issue in favor of #1565 (which reported a similar problem with Korea)