Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intl.DateTimeFormat error with formatRange #864

Open
cutterbl opened this issue Feb 23, 2024 · 4 comments
Open

Intl.DateTimeFormat error with formatRange #864

cutterbl opened this issue Feb 23, 2024 · 4 comments
Labels
bug c: datetime Component: dates, times, timezones s: blocked Status: the issue is blocked on upstream

Comments

@cutterbl
Copy link

Consider the following

const formatter = new Intl.DateTimeFormat("en-US", {
    weekday: "short",
    year: "numeric",
    month: "2-digit",
    day: "2-digit"
  });

const myDate = "2024-02-14T16:00:00.000Z";
const myDate2 = "2024-02-15T16:00:00.000Z";

console.log(formatter.formatRange(new Date(myDate), new Date(myDate2)))

What You Currently See

Wed, 2/14/2024 – Thu, 2/15/2024

What Is Expected

Wed, 02/14/2024 – Thu, 02/15/2024

If you call just format() then the output is according to the definition (2-digit month), but when using formatRange() you get an incorrect month output (numeric month).

It does this in all current major browser versions (Chrome, Edge, FF and Safari)

@sffc
Copy link
Contributor

sffc commented Feb 23, 2024

Thanks for the report. I verified that this seems to be an issue in either ICU or in how engines call ICU.

The range pattern gets selected from here:

https://www.unicode.org/cldr/charts/44/by_type/date_&_time.gregorian.html#153a46c24508d0d4

The selected pattern is E, M/d/y – E, M/d/y. The spec then says that this pattern should be changed to match the field widths in the request:

If no match was found from the previous step, check what the closest match is in the fallback locale chain, as in availableFormats. That is, this allows for adjusting the string value field's width, including adjusting between "MMM" and "MMMM", and using different variants of the same field, such as 'v' and 'z'.

https://unicode.org/reports/tr35/tr35-dates.html#intervalFormats

So it should change M to MM, but it seems something is missing and it is not doing that transformation.

The root cause may be https://unicode-org.atlassian.net/browse/ICU-12076

CC @anba @FrankYFTang @Constellation for input on whether there is anything in the engines that could be causing this behavior or if it is indeed inside of ICU.

@sffc sffc added bug c: datetime Component: dates, times, timezones labels Feb 23, 2024
@anba
Copy link
Contributor

anba commented Feb 26, 2024

Yes, this is caused by ICU. The spec actually allows this behaviour, though. FormatDateTimePattern selects the formatting options from rangeFormatOptions, which can have different options than what's stored in dateTimeFormat.

@sffc sffc added the s: blocked Status: the issue is blocked on upstream label Feb 26, 2024
@sffc
Copy link
Contributor

sffc commented Jun 24, 2024

Maybe related: https://g-issues.chromium.org/issues/346328635

@FrankYFTang
Copy link
Contributor

we need to figure is that came from CLDR pattern issue or not first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug c: datetime Component: dates, times, timezones s: blocked Status: the issue is blocked on upstream
Projects
None yet
Development

No branches or pull requests

4 participants