Test the format of a German date with a short weekday and no year

[MidnightDesign]

I've stumbled upon an inconsistency between V8 and JavaScriptCore. Formatting a date with a short weekday and no year in German results in the following strings:

V8: Sa., 24. Dezember JavaScriptCore: Sa. 24. Dezember (no comma after the weekday)

When the year is included (year: 'numeric'), JavaScriptCore does add a comma.

[Ms2ger]

Please add copyright and frontmatter: https://github.com/tc39/test262/blob/main/CONTRIBUTING.md#test-case-style

On what basis did you decide which implementation was correct?

[MidnightDesign]

On what basis did you decide which implementation was correct?

Because of the consistent behavior when including the year.

Edit: Maybe the version without a comma is the "correct"/spec-compliant version. Either way, the behavior between engines is inconsistent.

[MidnightDesign]

Can someone help me out with the esid? I don't think the local styles themselves are defined in the spec, are they?

[MidnightDesign]

I'm not sure if I'm reading it right, but if I do, I've found a source: In CLDR 42, in the file common/main/de.xml, there's the entry

<dateFormatItem id="MMMMEd">E, d. MMMM</dateFormatItem>

Edit: GitHub link

[MidnightDesign]

@ptomato Thank you for your very detailed response and trying to not discourage me. I will go back and try to make this more reproducible in the next days. But I do remember that I definitely used the latest Safari on the latest OSX.

Just to give you some background on why this is so important to me: I'm using Next.js which renders the page using Node on the server and then hydrates it on the client. If the HTML of the server and the client disagree, React throws an error. Well, in this case, Node.js renders the date differently from Safari, and this is spamming our Rollbar:

So I'm not just very picky about my commas in dates, but there's an actual problem I'm trying to solve. : )

[ptomato]

Cool, then I think my advice about JSC still applies, but maybe in reverse; we must both be testing with different versions, and one is newer than the other :smile:

According to eshost, the version I tested with was https://github.com/WebKit/WebKit/commit/41769648c46baef691c1b892b0aacd51ee51e784. I see a date of 2022-05-19 on that commit.

[MidnightDesign]

I just tested it in Safari 16.1 (18614.2.9.1.12) on MacOS Ventura (using Browserstack):

Maybe you provided slightly different options to the DateTimeFormat constructor.

I do get the problem with adding these kinds of tests here, but I also can't think of a better place.

[ptomato]

I've tested again today with JavaScriptCore built from the very latest commit:

>>> new Date(2022, 11, 24).toLocaleString('de', {weekday: 'short', day: 'numeric', month: 'long'})
"Sa., 24. Dezember"
>>> new Intl.DateTimeFormat('de', {weekday: 'short', day: 'numeric', month: 'long'}).format(new Date(2022, 11, 24))
"Sa., 24. Dezember"

I don't know which JSC commit Safari 16.1 was branched off of, but that might be a good place to start. Another possibility that occurred to me is that Safari the browser could be using different internationalization data than JSC does when built by itself?

[MidnightDesign]

Another possibility that occurred to me is that Safari the browser could be using different internationalization data than JSC does when built by itself?

I would pretty much assume that that's the case. Well, I guess I'll just have to add the year everywhere. Should I go ahead and close this PR?

[MidnightDesign]

For what it's worth, Safari also renders date time ranges in German differently from all other engines: It uses a different kind of dash/hyphen and different kinds of spaces around it.

[ptomato]

I'm still pretty sure that must be due to a CLDR update. (https://github.com/tc39/test262/pull/3676 is the recent fallout in test262 due to CLDR 42 using different kinds of spaces than previously.)