3

I have this function that returns a new Date instance with a number of days added or subtracted from a passed Date object.

function daysFrom(date, numDays) {
    var retDate = new Date();
    retDate.setDate(date.getDate() + numDays);
    return retDate;
}

But right now (in Pacific time zone), if I pass a date from September 19, 2018, my two dates are inconsistent in Standard vs Daylight Saving Time.

var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);

console.log(startDate, endDate);
// Tue Sep 18 2018 17:12:00 GMT-0700 (Pacific Daylight Time) Tue Nov 13 2018 20:05:02 GMT-0800 (Pacific Standard Time)

I guess they would be different because my returned date was instantiated today, since we're not in DST, but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.

And what's the mode called (DST vs Standard)?

Using current release of Chrome browser.

BBaysinger
  • 6,614
  • 13
  • 63
  • 132
  • The use of *Date.parse* in `new Date(Date.parse('19 September 2018 00:12:00 GMT'))` is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent. – RobG Nov 19 '18 at 09:02

3 Answers3

1

You need to clone the end date instead of initializing it with the current date:

function daysFrom(date, numDays) {
    var retDate = new Date(date.getTime());
    retDate.setDate(date.getDate() + numDays);
    return retDate;
}

var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);

console.log(startDate, endDate);

As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.

From MDN:

Until ECMAScript 2018 (edition 9), the format of the string returned by Date.prototype.toString was implementation dependent. Therefore it should not be relied upon to be in the specified format.

Robby Cornelissen
  • 91,784
  • 22
  • 134
  • 156
1

...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.

There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.

Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.

And what's the mode called (DST vs Standard)?

ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.

More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.

RobG
  • 142,382
  • 31
  • 172
  • 209
0

I think you mean to initialize retDate to date?

function daysFrom(date, numDays) {
    var retDate = new Date(date);
    retDate.setDate(date.getDate() + numDays);
    return retDate;
}
Jim B.
  • 4,512
  • 3
  • 25
  • 53