Incorrect value when adding week to date and crossing PST daylight savings

[fpintos]

Moment-timezone version which you use:

Version: "moment-timezone": "0.5.39" and "0.5.21"

Issue description:

Hello,

I want to confirm if I'm using something incorrectly or if there is an issue:

Adding a week to 2018-03-04T02:00:00-08:00 in PST gives me different results in moment, browser's Date and dotnet.

For example, with 5.39:

var moment = require("moment-timezone");
console.log(
  moment.utc("2018-03-04T02:00:00-08:00").tz("America/Los_Angeles").add(1, "weeks").toISOString(true)
);

OUTPUTS "2018-03-11T02:00:00.000-07:00"  <- Notice the "2AM" and "-7:00".

With 5.21:

OUTPUTS: "2018-03-11T01:00:00.000-08:00"  <- Notice the "1AM" and "-8:00".

However, browsers in a machine running PST, give a different date if we add 7-days' worth of milliseconds:

new Date(new Date("2018-03-04T02:00:00-08:00").getTime() + 604800000)
OUTPUTS: "Sun Mar 11 2018 03:00:00 GMT-0700 (Pacific Daylight Time)"  <- Notice the "3AM" and "-7:00"

dotnet seems to agree with the 3AM value (in a machine running PST):

TimeZoneInfo.ConvertTime(DateTimeOffset.Parse("2018-03-04T02:00:00-08:00").AddDays(7), TimeZoneInfo.Local).ToString("o")
OUTPUTS: "2018-03-11T03:00:00.0000000-07:00"  <- Notice the "3AM" and "-7:00"

Two questions:

• why values returned by moment changed between 5.21 and 5.39? change in timezone data?
• why values returned by moment do not match what browsers and dotnet return?

Thanks

[gilmoreorless]

why values returned by moment changed between 5.21 and 5.39?

The earlier behaviour in 0.5.21 was a bug (#738) where the old offset wasn't cleared correctly around time zone transitions. This was fixed in version 0.5.24.

why values returned by moment do not match what browsers and dotnet return?

This looks like a different bug in Moment Timezone, while the dotnet behaviour is correct.

1. Adding 1 week (or 7 days) to 2 AM, March 4 2018 for Los Angeles produces 2 AM, March 11 2018.
2. But that time doesn't technically exist, because the DST change means March 11 goes from 1:59:59 AM directly to 3 AM.
3. Moment should be auto-updating the time to move forward to 3 AM, as described in the Parsing ambiguities documentation.
4. However, that behaviour only seems to happen when parsing strings and not when adding/subtracting. This is very similar to the behaviour described in Incorrect date when manipulating time around DST change #562, and possibly the same bug as Add day returns wrong time on the day before a day that starts at 1:00 am #409.

// Parsing directly:
moment.tz('2018-03-11T02:00:00', 'America/Los_Angeles').toISOString(true)
// Correctly adjusted: '2018-03-11T03:00:00.000-07:00'

// Same date via addition:
moment.tz('2018-03-04T02:00:00', 'America/Los_Angeles').add(1, 'weeks').toISOString(true)
// Invalid time: '2018-03-11T02:00:00.000-07:00'