Bug 230827 – REGRESSION (iOS 15): Intl.DateTimeFormat returns 2 digit years when type is 'numeric'

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: JavaScriptCore

[David Webster]

This bug occurs in Safari on iOS 15.

When Intl.DateTimeFormat is formatting a year, and the configuration for year is 'numeric', it returns a two-digit year. However, I expect the full year. Previous versions returned the full year, and other browsers (including Safari 15 on OSX) return the full year.

Here's a code sample:

const dtf = new Intl.DateTimeFormat('en-AU', { timeZone: 'Australia/Melbourne', year: 'numeric' });
const date = new Date();
const parts = dtf.formatToParts(date);
const year = parts.find(part => part.type === 'year')
console.log(year.value)
// expected output is "2021", but in Safari 15 on iOS, it's "21".

You can try this at https://jsfiddle.net/davidwebster/0b6qfu34/5/

[Kevin Neal]

Thank you for filing. What version of iOS 15 are you using? I was not able to reproduce the bug using the latest iOS 15 beta.

[Radar WebKit Bug Importer]

<rdar://problem/83673541>

[David Webster]

I'm using version 15.0.

I'm using the Simulator in XCode because I don't have a real iPhone to test on. I can't find any way to use the latest iOS 15 beta in the simulator.

[Yusuke Suzuki]

Thank you for filing an issue!
I tried it in iOS 15 device and iOS 15 simulator, but I cannot reproduce this issue.
Both shows the "2021", expected behavior.

For now, I'll just add that as a regression test.

[Yusuke Suzuki]

Committed r283446 (242433@main): <https://commits.webkit.org/242433@main>

[Yusuke Suzuki]

Since we cannot reproduce this issue, we didn't change the code, but adding a test case to our stress tests to ensure that this is/will be happening. Thanks.

[Matt Carroll]

Can this please be reopened. It seems the bug still exists.

This test case passes:

```
const dtf = new Intl.DateTimeFormat('en-AU', { timeZone: 'Australia/Melbourne', year: 'numeric' });
const date = new Date(2021, 9, 2);
const parts = dtf.formatToParts(date);
const year = parts.find(part => part.type === 'year')
shouldBe(year.value, "2021")
```


This test case will fail:

```
const dtf = new Intl.DateTimeFormat('en-AU', { timeZone: 'Australia/Melbourne', year: 'numeric', month: '2-digit', day: '2-digit' });
const date = new Date(2021, 9, 2);
const parts = dtf.formatToParts(date);
const year = parts.find(part => part.type === 'year')
shouldBe(year.value, "2021") // actual is "21"
```

[Yusuke Suzuki]

(In reply to Matt Carroll from comment #7)
> Can this please be reopened. It seems the bug still exists.
> 
> This test case passes:
> 
> ```
> const dtf = new Intl.DateTimeFormat('en-AU', { timeZone:
> 'Australia/Melbourne', year: 'numeric' });
> const date = new Date(2021, 9, 2);
> const parts = dtf.formatToParts(date);
> const year = parts.find(part => part.type === 'year')
> shouldBe(year.value, "2021")
> ```
> 
> 
> This test case will fail:
> 
> ```
> const dtf = new Intl.DateTimeFormat('en-AU', { timeZone:
> 'Australia/Melbourne', year: 'numeric', month: '2-digit', day: '2-digit' });
> const date = new Date(2021, 9, 2);
> const parts = dtf.formatToParts(date);
> const year = parts.find(part => part.type === 'year')
> shouldBe(year.value, "2021") // actual is "21"
> ```

Thanks. The updated test case can reproduce the issue.
This looks like a data problem in AppleICU (not WebKit), and now tracked by AppleICU team at rdar://83597941.
So closing this issue since the issue is in system ICU, not in WebKit code.

[Yusuke Suzuki]

*** Bug 231545 has been marked as a duplicate of this bug. ***

[Matt Carroll]

Is there an ETA on when this will be fixed in iOS?

[Myles C. Maxfield]

(In reply to Matt Carroll from comment #10)
> Is there an ETA on when this will be fixed in iOS?

Apple does not comment on future products or releases.

[Matt Carroll]

Ok, thank you.

[Blake]

Has there been any update on this, we are still experiencing the issue?

[Blake]

Hi, this bug has been marked as resolved but we can see the error is still occurring. Is this being investigated further?

[Wojciech Maj]

I was also able to reproduce this bug on Safari 15.1 (17612.2.9.1.20) on macOS Monterey. So this is NOT exclusive to iOS.