Update expected formatting for CLDR 46

[anba]

No description provided.

[ptomato]

Happy to merge as-is once we give CLDR 46 a bit of time to percolate.

Alternatively, we could just make t2 be in a 2-digit month, and update the expected results accordingly. That would sidestep the issue, since it is irrelevant for spec compliance whether the leading 0 is printed or not. I'd prefer that, but it's also fine if you don't have more time to spend on this.

[anba]

Changing optionsAT to use month: "2-digit" doesn't seem to work:

1. Using only { month: "2-digit", timeZone: onlyOnce("Europe/Vienna") } doesn't work because other date-time parts are now missing which are required for other tests in this file.
2. Using { year: "numeric", month: "2-digit", day: "numeric", hour: "numeric", minute: "numeric", second: "numeric", timeZone: onlyOnce("Europe/Vienna") } allows to pass more tests, but then this test fails:

assert.sameValue(at.format(t.withCalendar(atCalendar).toPlainYearMonth()), `11${deMonthYearSeparator}1976`);

Because deMonthYearSeparator can either be "/" or "." depending on the month format:

• https://github.com/unicode-org/cldr/blob/c178f608668f49d36013c3588e7426edca8a5de3/common/main/de.xml#L2971
• https://github.com/unicode-org/cldr/blob/c178f608668f49d36013c3588e7426edca8a5de3/common/main/de.xml#L2974

[linusg]

Happy to merge as-is once we give CLDR 46 a bit of time to percolate.

Note that another update for CLDR 46 was already merged: #4283

[ptomato]

@anba Rather than changing the format to month: "2-digit", I meant more like changing this line from month 02 to month 10 and updating the expectations accordingly, so that whether a leading zero is printed is irrelevant.

But again, it's fine to not do that. One day we will figure out a good way to make tests not depend on golden output.

@linusg I would've said the same thing about #4283, FWIW. But CLDR 46 has been out for >3 months and there's already a 46.1 release, so I think enough time has passed now.