Timezones like US/Pacific, America/Los_Angeles are not switching between PST and PDT about moment

[daniellecrasiuc]

Hi, can I be assigned to this issue?

[sanchej]

Hi, can I be assigned to work on this issue?

[kalina559]

Hi,

Having the same issue with 'Europe/Copenhagen' timezone. It looks like moment.js is still using the Standard Time (+01:00) instead of DST (+02:00)

[kenyaplenty]

Hi @kalina559, are you still having this issue in local development or just production?

[kalina559]

@kenyaplenty in both

[kenyaplenty]

@kalina559 are you doing any specific checks between DST and standard time?

[kalina559]

@kenyaplenty nope, just calling tz() on a utc date

[ismurray]

This is something I'm also seeing for a number of different timezones. It seems that moment is not currently supporting DST at all for 2023 and beyond.

Example:

> let timeZone = 'America/Los_Angeles';
let winterDateStr = '2022-12-04T17:05';
let summerDateStr = '2022-06-04T17:05';
console.log('2022 Winter ISO Time  ' + moment.tz(winterDateStr, timeZone).toISOString());
console.log('2022 Winter is DST  ' + moment.tz(winterDateStr, timeZone).isDST());
console.log('2022 Summer ISO Time  ' + moment.tz(summerDateStr, timeZone).toISOString());
console.log('2022 Summer is DST  ' + moment.tz(summerDateStr, timeZone).isDST());

winterDateStr = '2023-12-04T17:05';
summerDateStr = '2023-06-04T17:05';
console.log('2023 Winter ISO Time  ' + moment.tz(winterDateStr, timeZone).toISOString());
console.log('2023 Winter is DST  ' + moment.tz(winterDateStr, timeZone).isDST());
console.log('2023 Summer ISO Time  ' + moment.tz(summerDateStr, timeZone).toISOString());
console.log('2023 Summer is DST  ' + moment.tz(summerDateStr, timeZone).isDST());

> 2022 Winter ISO Time  2022-12-05T01:05:00.000Z
 2022 Winter is DST  false
 2022 Summer ISO Time  2022-06-05T00:05:00.000Z
 2022 Summer is DST  true
 2023 Winter ISO Time  2023-12-05T01:05:00.000Z
 2023 Winter is DST  false
 2023 Summer ISO Time  2023-06-05T01:05:00.000Z
 2023 Summer is DST  false

This also seems related to this similar issue: #6114

[sanchej]

@ismurray This is weird, but when I ran your code in my own environment, I received the following output:

2022 Winter ISO Time  2022-12-05T01:05:00.000Z
2022 Winter is DST  false
2022 Summer ISO Time  2022-06-05T00:05:00.000Z
2022 Summer is DST  true
2023 Winter ISO Time  2023-12-05T01:05:00.000Z
2023 Winter is DST  false
2023 Summer ISO Time  2023-06-05T00:05:00.000Z
2023 Summer is DST  true

I also tried it with 'Europe/Copenhagen' to test @kalina559 's issue and I got:

2022 Winter ISO Time  2022-12-04T16:05:00.000Z
2022 Winter is DST  false
2022 Summer ISO Time  2022-06-04T15:05:00.000Z
2022 Summer is DST  true
2023 Winter ISO Time  2023-12-04T16:05:00.000Z
2023 Winter is DST  false
2023 Summer ISO Time  2023-06-04T15:05:00.000Z
2023 Summer is DST  true

Am I perhaps missing something? Could you try running your code again to see if the error is still occurring?

[ismurray]

@sanchej this may seem like a silly question, but are you potentially using moment-timezone instead of moment? I ask because this works correctly for me with moment-timezone, but not with moment.

moment:

import moment from 'moment';
// ...

> let timeZone = 'America/Los_Angeles';
let winterDateStr = '2022-12-04T17:05';
let summerDateStr = '2022-06-04T17:05';
console.log('2022 Winter ISO Time  ' + moment.tz(winterDateStr, timeZone).toISOString());
console.log('2022 Winter is DST  ' + moment.tz(winterDateStr, timeZone).isDST());
console.log('2022 Summer ISO Time  ' + moment.tz(summerDateStr, timeZone).toISOString());
console.log('2022 Summer is DST  ' + moment.tz(summerDateStr, timeZone).isDST());

winterDateStr = '2023-12-04T17:05';
summerDateStr = '2023-06-04T17:05';
console.log('2023 Winter ISO Time  ' + moment.tz(winterDateStr, timeZone).toISOString());
console.log('2023 Winter is DST  ' + moment.tz(winterDateStr, timeZone).isDST());
console.log('2023 Summer ISO Time  ' + moment.tz(summerDateStr, timeZone).toISOString());
console.log('2023 Summer is DST  ' + moment.tz(summerDateStr, timeZone).isDST());

> 2022 Winter ISO Time  2022-12-05T01:05:00.000Z
 2022 Winter is DST  false
 2022 Summer ISO Time  2022-06-05T00:05:00.000Z
 2022 Summer is DST  true
 2023 Winter ISO Time  2023-12-05T01:05:00.000Z
 2023 Winter is DST  false
 2023 Summer ISO Time  2023-06-05T01:05:00.000Z
 2023 Summer is DST  false

moment-timezone:

import moment from 'moment-timezone';
// ...

let timeZone = 'America/Los_Angeles';
let winterDateStr = '2022-12-04T17:05';
let summerDateStr = '2022-06-04T17:05';
console.log('Winter ISO Time  ' + _momentTimezone.tz(winterDateStr, timeZone).toISOString());
console.log('Winter is DST  ' + _momentTimezone.tz(winterDateStr, timeZone).isDST());
console.log('Summer ISO Time  ' + _momentTimezone.tz(summerDateStr, timeZone).toISOString());
console.log('Summer is DST  ' + _momentTimezone.tz(summerDateStr, timeZone).isDST());

winterDateStr = '2023-12-04T17:05';
summerDateStr = '2023-06-04T17:05';
console.log('Winter ISO Time  ' + _momentTimezone.tz(winterDateStr, timeZone).toISOString());
console.log('Winter is DST  ' + _momentTimezone.tz(winterDateStr, timeZone).isDST());
console.log('Summer ISO Time  ' + _momentTimezone.tz(summerDateStr, timeZone).toISOString());
console.log('Summer is DST  ' + _momentTimezone.tz(summerDateStr, timeZone).isDST());

> Winter ISO Time  2022-12-05T01:05:00.000Z
 Winter is DST  false
 Summer ISO Time  2022-06-05T00:05:00.000Z
 Summer is DST  true
 Winter ISO Time  2023-12-05T01:05:00.000Z
 Winter is DST  false
 Summer ISO Time  2023-06-05T00:05:00.000Z
 Summer is DST  true

Versions:

    "moment": "2.29.4"
    "moment-timezone": "0.5.43"

running in Chrome Version 111.0.5563.146 (Official Build) (arm64)

[mimen]

It seems like using moment-timezone might be a solution to our issues, but that would be a significant change in our codebase.

Has anybody been able to find the underlying issue inside of moment.js? I'm not sure how active the team is on this as the project is no longer being developed, and the last update was made about a year ago... the best solution at this point would likely be to fork and patch. @daniellecrasiuc @sanchej @kalina559 @ismurray

[sanchej]

Hey @ismurray , sorry I was busy but yes I was running moment timezone, I will continue to look into moment

[sanchej]

@mimen I will continue to look into it, being transparent, I am taking a class that wants us to contribute to an open-source project so I will try to tackle this soon.

[gilmoreorless]

Moment Timezone includes OLD AND DEPRECATED files called moment-timezone-with-data-2012-2022.js (and .min.js). As the filename indicates, they only have data up to and including the year 2022. Given the number of reports of "broken" code as we've hit 2023, I'm guessing that a lot of people are using these files without realising that their code should have been changed years ago. The most recent versions of Moment Timezone have added deprecation warnings to these files, and they'll be completely removed in a future release.

Here are my suggestions for everyone with issues around incorrect DST rules starting this year:

1. Check if you're actually using moment-timezone, not core moment. If your code says moment.tz(), you're using moment-timezone. Core moment doesn't include any time zone rules, and just relies on the native Date object.
2. Check how you're including moment-timezone. If you're including a file called moment-timezone-with-data-2012-2022.min.js or similar, this is the problem.
   1. You'll need to change the reference to moment-timezone-with-data-10-year-range instead. This is a rolling 10-year range that is updated on every release. For example, any release built in 2023 will include data from 2018 to 2028.

[mimen]

Thanks so much @gilmoreorless for providing this info.

For reference for others, I was able to fix this by including this file at the end of my ember-cli-build.js file.

app.import('node_modules/moment-timezone/builds/moment-timezone-with-data-10-year-range.min.js');

I would suggest that this build should be used by default, but I'm unsure of the implications of that. It seems better than having the default behavior being broken in 2023...