Bug on DSTChange convesion for Asia/Amman country

[vittal288]

Moment-timezone version which you use:

Version :0.5.34

Note: many issues are resolved if you just upgrade to the latest version

Issue description:

Recently we have migrated this package from 0.5.12 to 0.5.34 and we see the following bug latest version.

We are trying to convert DST change for Asia/Amman and which is returning the wrong results for 25FEB2022 date and for the rest of the dates which is fine and the bug exist for upcoming years too on 25FEBXXXX years, please validate once and release new patches to fix this issue.

moment.tz('Asia/Amman').set({year:2022, month:01,date:25,hour:0,minute:0,second:0,millisecond:0}).format() above line of code which is returning wrong for 25FEB2022 and 25FEB2023 and so on..... result : '2022-02-25T01:00:00+03:00' and it should be '2022-02-25T00:00:00+03:00'

[AsharDweedar]

This solved it temporarly:

const moment = require("moment-timezone");
const zone = moment.tz.zone("Asia/Amman");
const startOfSummerTime = moment().tz("Asia/Amman").day(26).month(1).startOf("day").valueOf();
// index of year 2022 for summer time start is 85
zone.untils[85] = startOfSummerTime; // 1645740000000;

I tried to change the packed/latest.js file using the pack method in the utils and got:

Asia/Amman|LMT EET EEST EET|-2n.I -20 -30 -30|0121212121212121212121212121212121212121212121212121212121212121212121212121212121212321212121212121212121212121212121|-1yW2n.I 1HiMn.I KL0 1oN0 11b0 1oN0 11b0 1pd0 1dz0 1cp0 11b0 1op0 11b0 fO10 1db0 1e10 1cL0 1cN0 1cL0 1cN0 1fz0 1pd0 10n0 1ld0 14n0 1hB0 15b0 1ip0 19X0 1cN0 1cL0 1cN0 17b0 1ld0 14o0 1lc0 17c0 1io0 17c0 1io0 17c0 1So0 y00 1fc0 1dc0 1co0 1dc0 1cM0 1cM0 1cM0 1o00 11A0 1lc0 17c0 1cM0 1cM0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 4bX0 Dd0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 Lz0 1C10 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0|25e5

I really don't understand how the method works does this sound good for a PR?

[gilmoreorless]

This is the correct behaviour. In September 2021 the Jordanian Government announced a change to the timing of DST: https://www.timeanddate.com/news/time/jordan-february-dst-start.html

Clocks are to be set back by 60 minutes as of 1am of the last Friday of October every year, bringing the Kingdom two hours ahead of Greenwich Mean Time, while they will be set forward one hour on the last Thursday of February as of next year.

For Jordan, the switch to DST happens at midnight at the end of the day. So 23:59:59.999 on Thursday 24th Feb 2022 ticks over to 01:00:00.000 on Friday 25th Feb. Therefore the time of 00:00:00.000 on Feb 25 doesn't exist, and Moment Timezone will account for that and round up to a time that does exist. More details are in the documentation at https://momentjs.com/timezone/docs/#/using-timezones/parsing-ambiguous-inputs/

The change to the switch rules was added in IANA tzdb release 2021b, which was included in Moment Timezone 0.5.34.

[ichernev]

@gilmoreorless thank you!

I've seen this question asked again and again, you can write up some of your excellent answers in a FAQ and we can put it up on the momentjs.com page :)

Other than that, doing DST at midnight is the dumbest thing I've seen, beaten only by DST at midnight at start/end of month :sob:

[AsharDweedar]

For all users in "Asia/Amman" timezone; new changes are on version 0.5.38... you need to update again. @vittal288