Date has slight difference and is not the same as the one inputted.

[Sonchucks]

There seems to be an issue when sending in a dateString or dateObject where the baseDate returns a strange offset when setting your computers timezone to specific ones.

Computer timezone set to "America/Cuiaba" or GMT-0400.

/**
 * started date:  Mon Jun 14 2021 08:00:00 GMT-0400 (Amazon Standard Time)
 * started unix:  1497355200000
 * started timezone:  240
 * 
 * started baseDate:  Sun Dec 31 1899 00:00:00 GMT-0344 (Amazon Standard Time)
 * started baseUnix:  -2209061740000
 * started baseTimezone:  224
 */

This leads to me getting 2021-06-14 07:59:40 AM as the value instead of 2021-06-14 08:00:00 AM in the excel file.

This also occurs when setting the computers timezone to "America/Recife" or GMT-0300 where I get the following

/**
* started date:  Mon Jun 14 2021 08:00:00 GMT-0300 (Brasilia Standard Time)
* started unix:  1497351600000
* started timezone:  180
*
* started baseDate:  Sun Dec 31 1899 00:00:00 GMT-0219 (Brasilia Standard Time)
* started baseUnix:  -2209066824000
* started baseTimezone:  139
*/

In turn returning 2021-06-14 07:59:23 AM instead of 2021-06-14 08:00:00 AM

I've seen at least two issues that are describing a similar problem and I imagine it's due to the same thing where baseDate is returning a strange timezoneOffset.

Issue#2152
Issue#2304

So could somebody explain to me the reasoning behind the datenum function on line 2773?

var basedate = new Date(1899, 11, 30, 0, 0, 0); // 2209161600000
function datenum(v, date1904) {
	var epoch = v.getTime();
	if(date1904) epoch -= 1462*24*60*60*1000;
	var dnthresh = basedate.getTime() + (v.getTimezoneOffset() - basedate.getTimezoneOffset()) * 60000;
	return (epoch - dnthresh) / (24 * 60 * 60 * 1000);
}

Is there a reason why we have to do the timezoneOffset, instead of just doing the following? Which would just basically rely on the user sending down the proper value, at least when using the aoa_to_sheet function and in turn sheet_add_aoa.

function datenum(v) {
	var epoch = v.getTime();
	return epoch / (24 * 60 * 60 * 1000);
}

I removed the date1904 var from this function as well because in all instances of this specific function being used in the code seems to never send down a secondary variable.

[SheetJSDev]

Excel normally stores dates as date codes, which represent a time difference from the epoch. The Epoch is actually timezone-specific so that 1:23:00 PM will be the same irrespective of your computer timezone. From the parsing side, we have to take the date code and interpret in the current timezone (not UTC). Likewise in the writing side, we have to interpret a date value in the current timezone (not UTC). That fundamental mismatch is why timezone offsets come into play

As for date1904: To be consistent with Lotus 1-2-3, Excel treats the year 1900 as if it were a leap year (February 29 1900 is a valid Excel date but it is not a real JS date). To "fix" the issue, Excel also supports a 1904 system that skips over the problematic date. The option in Excel is "Use 1904 date system"

[reviewher]

#2196