When date strings are parsed with new Date() they are always treated as UTC. The resulting time will also be midnight; for example 2017-10-08 is parsed as 2017-10-08T00:00:00.000Z. When using this resulting date in a timezone that is a negative offset, ie America/Chicago which is -05:00, you will end up with the previous day. A .getDate() called on a date parsed from 2017-10-08 will yield 7 in America/Chicago.
If UTC wasn't the intention when parsing dates @sanx , I would reject this PR and instead fix the instantiation of new Date() to use 3 parameters (for year, month, day) as these are always assumed to be localtime.
Fix #2 while maintaining backwards compatibility
When date strings are parsed with
new Date()they are always treated as UTC. The resulting time will also be midnight; for example2017-10-08is parsed as2017-10-08T00:00:00.000Z. When using this resulting date in a timezone that is a negative offset, ieAmerica/Chicagowhich is-05:00, you will end up with the previous day. A.getDate()called on a date parsed from2017-10-08will yield7inAmerica/Chicago.If UTC wasn't the intention when parsing dates @sanx , I would reject this PR and instead fix the instantiation of
new Date()to use 3 parameters (for year, month, day) as these are always assumed to be localtime.