V8 assertion timezone.js - difference between UTC and Etc/UTC

[pompi...@gmail.com]

I'm packaging V8 5.9.116.17 on Arch Linux using system installation of ICU 59.1.

Everything seems compatible apart the fact that two functions u_strToUpper and u_strToLower now are in ustring.h, so I added the header to i18n.cc

--- i18n.cc 2017-05-10 11:53:57.215319733 +0200

+++ i18n_patched.cc 2017-05-10 11:53:50.241855309 +0200

@@ -29,6 +29,7 @@

 #include "unicode/smpdtfmt.h"

 #include "unicode/timezone.h"

 #include "unicode/uchar.h"

+#include "unicode/ustring.h"

 #include "unicode/ucol.h"

 #include "unicode/ucurr.h"

 #include "unicode/unum.h"

Build is fine if warnings are not considered errors.

Then i run the checks like so:

tools/run-tests.py --no-presubmit --outdir=out.gn --buildbot --arch=x64 --mode=Release

One assert in timezone.js (https://chromium.googlesource.com/v8/v8.git/+/5.9-lkgr/test/intl/date-format/timezone.js) fails saying that Etc/UTC is found instead of UTC. Shouldn't be UTC a shortcut to Etc/UTC ? Is the assert wrong or I have to configure ICU 59.1 to a specific behavior ?

Thank you, the assertion error is below.

=== intl/date-format/timezone ===                                              

/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:105: Error: Failure: expected <UTC>, found <Etc/UTC>.

  throw new Error(message);

  ^

Error: Failure: expected <UTC>, found <Etc/UTC>.

    at fail (/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:105:9)

    at assertEquals (/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:114:5)

    at /home/marcs/DevLab/aur/v8/src/v8/test/intl/date-format/timezone.js:38:1

Command: /home/marcs/DevLab/aur/v8/src/v8/out.gn/Release/d8 --test --random-seed=937151913 --no-turbo --allow-natives-syntax --nohard-abort --nodead-code-elimination --nofold-constants /home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/utils.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/regexp-prepare.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/date-format/timezone.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/regexp-assert.js

=== intl/date-format/timezone ===                                              

/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:105: Error: Failure: expected <UTC>, found <Etc/UTC>.

  throw new Error(message);

  ^

Error: Failure: expected <UTC>, found <Etc/UTC>.

    at fail (/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:105:9)

    at assertEquals (/home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js:114:5)

    at /home/marcs/DevLab/aur/v8/src/v8/test/intl/date-format/timezone.js:38:1

Command: /home/marcs/DevLab/aur/v8/src/v8/out.gn/Release/d8 --test --random-seed=937151913 --allow-natives-syntax --nohard-abort --nodead-code-elimination --nofold-constants /home/marcs/DevLab/aur/v8/src/v8/test/intl/assert.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/utils.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/regexp-prepare.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/date-format/timezone.js /home/marcs/DevLab/aur/v8/src/v8/test/intl/regexp-assert.js

[Daniel Ehrenberg]

Upgrading to ICU 59 is something that's in progress upstream. Those
particular issues are addressed by recent or out-for-review patches:

- https://chromium-review.googlesource.com/c/499609/2/src/intl.cc
- https://chromium-review.googlesource.com/c/496406/

Do things work for you if you patch those in locally?

Dan

> --
> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[pompi...@gmail.com]

I moved up to 5.9.221.20: intl.status and test262.status are already patched.

The patches for the C++ source files fix the issue with the test of UTC Etc/UTC. As a side note: I had to apply the patch to the i18n.cc source file, instead of intl.cc and src/objects/int-objects.cc.

Patch is below:

diff --git a/src/i18n.cc b/src/i18n.cc

index 79a70daf62..7a8d847034 100644

--- a/src/i18n.cc

+++ b/src/i18n.cc

@@ -28,7 +28,7 @@

 #include "unicode/rbbi.h"

 #include "unicode/smpdtfmt.h"

 #include "unicode/timezone.h"

-#include "unicode/uchar.h"

+#include "unicode/ustring.h"

 #include "unicode/ucol.h"

 #include "unicode/ucurr.h"

 #include "unicode/unum.h"

@@ -180,7 +180,13 @@ void SetResolvedDateSettings(Isolate* isolate,

   icu::UnicodeString canonical_time_zone;

   icu::TimeZone::getCanonicalID(time_zone, canonical_time_zone, status);

   if (U_SUCCESS(status)) {

-    if (canonical_time_zone == UNICODE_STRING_SIMPLE("Etc/GMT")) {

+    // In CLDR (http://unicode.org/cldr/trac/ticket/9943), Etc/UTC is made

+    // a separate timezone ID from Etc/GMT even though they're still the same

+    // timezone. We'd not have "Etc/GMT" here because we canonicalize it and

+    // other GMT-variants to "UTC" in intl.js and "UTC" is turned to "Etc/UTC"

+    // by ICU before getting here.

+    DCHECK(canonical_time_zone != UNICODE_STRING_SIMPLE("Etc/GMT"));

+    if (canonical_time_zone == UNICODE_STRING_SIMPLE("Etc/UTC")) {

       JSObject::SetProperty(

           resolved, factory->NewStringFromStaticChars("timeZone"),

           factory->NewStringFromStaticChars("UTC"), SLOPPY).Assert();