Converting dates (from JS) gets incorrect results if crossing DST boundary

(Actually also with different timezones, but you state in the README you make a choice of not handling timezones at all, so let’s focus on the DST issue.)

This is a little difficult to explain though. Let’s say we ended Daylight Saving Time last Sunday. Let d1 be a date today, and d2 be a date exactly a week ago.

To test more easily, let’s say we set dateNF: 'yyyy-mm-dd"T"hh:MM:ss'. Then put d1 and d2 in two columns in the same row and export a csv. (The bug is not actually related to csv, it’s just easier to test if we convert to string.)

Expected: the time part (after T) is identical for both.

Actual: the time part for d2 will be off by one hour (e.g. 10:28 instead of 11:28).

The reason for this is the dnthresh constant is calculated based on the timezone offset of the current time as of when the library is loaded. So dates with any other offset (including same timezone but different DST status) will break the calculation.

PR coming up in a few minutes.

[cemremengu]

Spent hours trying to figure out why our tests were failing 😄

Any ETA for the patch release?

[SheetJSDev]

Thanks for looking into this @lalomartins !

The overarching problem is that Excel doesn’t actually have a proper concept of time. It’s shoehorned into the numeric model in a very simplistic way, where each calendar day has 86400 equally-spaced seconds and midnight is pinned to 0. This very clearly creates problems around DST.