Timezone Error in v0.5.45

[AleTid5]

Environment

Local timezone: Barcelona (GMT+1)
Aimed timezone: Almaty (GMT+6)

For bug reports, please run the following code in your environment and include the output:

{
  moment: '2.30.1',
  momentTz: '0.5.45',
  date: 'Thu Feb 22 2024 16:06:48 GMT+0100 (Central European Standard Time)',
  intlZone: 'Europe/Madrid'
}

Issue description

I'm trying to format the timezone of Almaty in my web app and found that for the first day of March at midnight, the library is returning 29/02/2024 23:00:00. I'm not sure if this is expected behaviour or not, but I can't find a workaround to display 01/03/2024 00:00:00.

[gilmoreorless]

This is looking like a bug to me. Kazakhstan is unifying to a single time zone at that exact time (see #1095), so Asia/Almaty moves from UTC+6 to UTC+5 at the very start of March.

However, the way this should play out is:

• 2023-02-29 23:59:59+06:00 is followed one second later by 2023-02-29 23:00:00+05:00 (so midnight hasn't actually happened).
• One hour later, the zone hits 2023-03-01 00:00:00+05:00.
• When you ask for 2023-03-01 00:00:00 you should be getting that later time ^.

Moment Timezone has a way of handling ambiguous times (e.g. when the same time happens twice), but that shouldn't be applying here. For Almaty, the times 23:00:00 to 23:59:59 will happen twice on Feb 29, but Mar 1 00:00:00 only happens once.

The curious thing is that other time zones that have had DST transitions at midnight (like Brazil) are handled correctly:

moment.tz('2019-02-16 23:00:00', 'America/Sao_Paulo').format(); // '2019-02-16T23:00:00-02:00'
moment.tz('2019-02-16 23:59:59', 'America/Sao_Paulo').format(); // '2019-02-16T23:59:59-02:00'
moment.tz('2019-02-17 00:00:00', 'America/Sao_Paulo').format(); // '2019-02-17T00:00:00-03:00'
// This last one is actually one hour later than the time above, due to ambiguities listed earlier

There's a poorly-documented data property to assist with the times that happen twice due to clock changes: moment.tz.moveAmbiguousForward. By default it's false (so the first instance of the duplicate time will be chosen), but setting it to true makes the library choose the later instance of the time. What's weird is that it does affect this Almaty time, even though midnight only happens once. 🤔

moment.tz.moveAmbiguousForward = false; // the default
moment.tz('2024-03-01 00:00:00', 'Asia/Almaty').format(); // '2024-02-29T23:00:00+05:00'

moment.tz.moveAmbiguousForward = true;
moment.tz('2024-03-01 00:00:00', 'Asia/Almaty').format(); // '2024-03-01T00:00:00+05:00'

I'll have to dig further to work out why this is happening only in this one case.