Same date is written differently in Chrome/Safari and other browsers

[lekrus]

Hello,

Running your sample: http://sheetjs.com/demos/writexlsx.html
There is a date cell that holds "2014-02-19T14:30Z" value

When running script in Chrome (v67), Safari, resulting XSLX file has the following value:
41689.729212962964 that converts to 2014-02-19T14:30:04Z

in other browsers (Edge, Firefox) that results in proper value:
41689.729166666664 that converts to 2014-02-19T14:30:00Z

Please notice difference in seconds.

[SheetJSDev]

I cannot reproduce on OSX 10.13.4 (High Sierra) using Chrome 67 (67.0.3396.87) in the Eastern Timezone (-0400). Currently new Date().getTimezoneOffset() evaluates to 240

What operating system are you using and what timezone is your computer currently set to? Also, what does new Date().getTimezoneOffset() evaluate to?

[lekrus]

Thanks for checking,

We reproduce that both on Mac (MacOS High Sierra 10.13.5 (17F77)) and Windows (10, Server 2016).
Nevertheless, to prepare a clean test case I tried to reproduce that on a clean computer (started test Amazon AWS instance and setup Chrome and Firefox only, Windows Server 2016 Base AMI)

Seems like the issue depends on local computer timezone, I opened Date&Time settings and changed local computer time zone.
UTC works fine, most negative offsets also work fine, most of positive offsets work bad
Samples:
GMT+02:00 gives 41689.729212962964 (e.g. [2/19/2014 5:30:04 PM] - see 04 seconds added)
GMT+07:00 gives 41689.89587962963 (e.g. [2/19/2014 9:30:04 PM] - see 04 seconds added)
GMT-03:00 gives 41689.47857638889 (e.g. [2/19/2014 11:29:09 AM] - see time changed a lot)
GMT-09:00 gives 41689.270416666666 (e.g. [2/19/2014 6:29:24 AM] - again, big time difference)

I guess the issue is with some rounding of digits when calculating OA date format,
could you please double-check?

[hanyuzhou2006]

The reason is Daylight Saving Time (DST) changes in diferent years.
chrome 67+ implement this changes.
so this cause a bug with chrome 67+.

[SheetJSDev]

Sub-minute difference in chrome is almost certainly due to a V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=7863 (in many timezones, the date epoch had a timezone offset with a seconds component. V8 does not handle it correctly)

Closing in favor of #1212