datenum() not accounting for DST properly

Creating this issue as recommended in #832.

Here is a jsfiddle to witness the problem: https://jsfiddle.net/gtt2srcu/

I have some problems with the datenum function, not behaving correctly when the v is not in the same timezone offset as the current time (ex. current time has DST offset and v does not have DST offset). After playing around with the code, I believe the offsetting needs to be dependent on the v value instead of current time, like this:

var basedate = new Date(1899, 11, 30, 0, 0, 0);
var basetimestamp = basedate.getTime();
var baseoffset = basedate.getTimezoneOffset();
function datenum(v/*:Date*/, date1904/*:?boolean*/)/*:number*/ {
	var epoch = v.getTime();
	if(date1904) epoch -= 1462*24*60*60*1000;
	// Account for offset differences between the basedate and v...
	var adj = (v.getTimezoneOffset() - baseoffset) * 60000;
	return (epoch - basetimestamp - adj) / (24 * 60 * 60 * 1000);
}

This is because if basedate and v have a different offset, we need to compensate this effect by applying the difference on the numerical value provided to excel. The offset of the current time does not seem relevant.

It’s possible that the numdate function suffers from the same problem, but I haven’t digged through it.

[EBMike]

@SheetJSDev Maybe add a third date “type” which is just an iso-date string. Not everyone needs a “time” on their dates. In fact, for our code, every datetime we encounter is broken into 2 excel columns (for date and time).

To respond to the server timezone vs client timezone comment above… yes, thats the problem we were encountering that become much harder after the change noted in #832. I did not bring it up in the issue because I didn’t think it was relevant at the time, and the issues noted in #832 would be obvious enough.

[SheetJSDev]

v0.16.0 changed date handling. Please re-test against a version at or above v0.16.0 and report back if issues persist