Bug 196395 - REGRESSION(r243512): Change locale of test in intl-datetimeformat.js
Summary: REGRESSION(r243512): Change locale of test in intl-datetimeformat.js
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-03-29 04:16 PDT by Diego Pino
Modified: 2019-04-02 13:44 PDT (History)
5 users (show)

See Also:


Attachments
Patch (5.78 KB, patch)
2019-03-29 04:18 PDT, Diego Pino
no flags Details | Formatted Diff | Diff
Screenshot of test executed in JavaScript console using 'en' locale (5.25 KB, image/png)
2019-04-01 04:33 PDT, Diego Pino
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Pino 2019-03-29 04:16:52 PDT
REGRESSION(r243512): Change locale of test in intl-datetimeformat.js
Comment 1 Diego Pino 2019-03-29 04:18:33 PDT
Created attachment 366263 [details]
Patch
Comment 2 Diego Pino 2019-03-29 04:20:51 PDT
r243512 modifies Intl.DateTimeFormat to obey 2-digit hour. A test was added to test 2-digit hour in Russian using 12-hour setting as true and false. In the former case, the expected string appends the string 'AM' in Russian. This localized string made GTK-based ports fail since according to Glib the 'am_pm' values in Russian are not localized (https://github.molgen.mpg.de/git-mirror/glibc/blob/master/localedata/locales/ru_RU#L152).
    
This patch keeps the same test but changes locale to 'en' to prevent the test from failing.
Comment 3 Diego Pino 2019-03-29 04:38:08 PDT
FWIW, the Chromium ticket that fixes this issue features the original test using the 'ru' locale, but 'am_pm' string is not localized.

https://chromium-review.googlesource.com/c/v8/v8/+/1529260/3/test/intl/regress-527926.js
Comment 4 Andy VanWagoner 2019-03-29 12:35:02 PDT
The original issue was about the ru locale, but I understand not relying on ru data being complete. I believe the '2-digit' hour was also sometimes ignored, so this is probably still a good enough test for us.
Comment 5 Andy VanWagoner 2019-03-29 12:35:43 PDT
(In reply to Andy VanWagoner from comment #4)
> The original issue was about the ru locale, but I understand not relying on
> ru data being complete. I believe the '2-digit' hour was also sometimes
> ignored, so this is probably still a good enough test for us.

*was sometimes ignored in 'en'.
Comment 6 Alexey Proskuryakov 2019-03-29 12:57:46 PDT
Perhaps the subtest can be split into a separate file, to have custom results for platforms that need them?
Comment 7 Diego Pino 2019-04-01 04:28:36 PDT
I run the test in an old version of WebKit (WebKit v2.22.6), and the 2-digit issue happens also if 'en' locale is used:

> Intl.DateTimeFormat('en', {minute: '2-digit', hour: '2-digit', hour12: true, timezone: 'UTC'}).format(1e7)
< "3:46 AM"

(See attachment)

Regarding isolating the test in a different file (so there's different outputs per platform), the problem is the test is valid for GTK but it fails because of the localized string. So this is more about expecting a different actual result per platform. In fact, the original issue that r243512 solves states that valid outputs for this test are:

03:00
03:00 AM (or a Cyrillic alternative to "AM")

https://bugs.webkit.org/show_bug.cgi?id=195974

(In r243512, 10e7 is used instead of a number value equivalent to '03:00 AM').

So an alternative solution would be to modify the test to expect all these possible valid outputs. For instance:

shouldBeTrue("['02:46 ДП', '02:46 AM', '02:46'].includes(Intl.DateTimeFormat('ru', { minute:'2-digit', hour:'2-digit', hour12: true, timeZone: 'UTC' }).format(1e7))");

Whether to change the locale to 'en' or adapt the test to expect different valid outputs works for me, although I have a preference for changing the locale to a language where am_pm string is normally translated (as in English), so the output of the test is different than the same test where `hour12: false`.
Comment 8 Diego Pino 2019-04-01 04:33:04 PDT
Created attachment 366394 [details]
Screenshot of test executed in JavaScript console using 'en' locale
Comment 9 Michael Catanzaro 2019-04-01 05:41:32 PDT
(In reply to Alexey Proskuryakov from comment #6)
> Perhaps the subtest can be split into a separate file, to have custom
> results for platforms that need them?

I think this would be a good idea if we had more platform-specific failures.

This is a sensitive test where it's possible to test the thing we want to test in ways that work cross-platform and ways that don't. E.g. Andy has previously rewritten checks that failed for newer versions of ICU to not be sensitive to the ICU version. It could have been done with subtests, like you suggest, but making the test work more generally was fine too. I suspect it's easier to maintain as just one test, though, so r=me.
Comment 10 Michael Catanzaro 2019-04-01 05:51:12 PDT
Comment on attachment 366263 [details]
Patch

It might be more interesting to test a locale other than English, but like Andy says, the goal of this test was to show that hour:'2-digit' and hour:'numeric' give different output, so it seems fine.

Why not just test 'pt-BR' though? Since it worked above, we already know it's localized properly on all the platforms WebKit cares about, right?
Comment 11 WebKit Commit Bot 2019-04-02 07:31:33 PDT
Comment on attachment 366263 [details]
Patch

Clearing flags on attachment: 366263

Committed r243740: <https://trac.webkit.org/changeset/243740>
Comment 12 WebKit Commit Bot 2019-04-02 07:31:34 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 Radar WebKit Bug Importer 2019-04-02 13:44:09 PDT
<rdar://problem/49532466>