That was a good guess! Your comment provided some helpful motivation to go look into it. :) It seems to have actually been a typo-misuse of moment.tz's very si

That was a good guess! Your comment provided some helpful motivation to go look into it. :) It seems to have actually been a typo-misuse of moment.tz's very similar but very different constructor patterns. To illustrate, imagine we have a date "2020-01-01", an offset tz "America/Vancouver", and "America/Toronto" as the locale's timezone. moment(date).tz(offset) says "interpret date in its given tz, falling back to the locale tz if not given, then reinterpret it via the offset tz". So the date "2020-01-01" with no encoded tz data is interpreted as midnight in the locale's tz, America/Toronto. That is then reinterpreted in the offset timezone America/Vancouver, so calling .format() on it gives the result "2019-12-31T21:00:00-08:00" -- midnight on New Year's Eve in Toronto was 9 PM on Dec 31st in Vancouver. Offset here is changing the output, not the input. moment.tz(date, offset) says "interpret date in its given tz, falling back to offset as the tz if not given". So the date "2021-01-01" with no tz data is interpreted as midnight in the offset tz, "America/Vancouver". Now calling .format() gives "2020-01-01T00:00:00-08:00", or midnight in Vancouver, which would be 3 AM in Toronto. Glad to have it fixed.