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

Normative: Revert U+2212 (Unicode minus sign) as a valid character in timezone offsets #3334

Merged
merged 1 commit into from
Jul 17, 2024

Conversation

justingrant
Copy link
Contributor

Following ISO-8601, #2781 introduced U+2212 (Unicode minus) as an alias for the regular ASCII minus sign for use in time zone offsets.

There's two new data that lead me to believe that this was a mistake, and that we should revert this change.

The first is that the newly-released RFC 9557 (the string format standard that Temporal uses) disallows non-ASCII characters. Its predecessor RFC 3339 also disallows non-ASCII characters. So strings that follow the current (since 2022) ECMAScript spec could be rejected by RFC 9557 clients.

The second new data is feedback from implementers of a Rust version of Temporal that this single obscure character in the grammar will incur a performance cost because they must now use Rust strings instead of plain U8 ASCII data. See
tc39/proposal-temporal#2843 (comment)

This performance issue doesn't seem to be limited to Rust. Any native implementation would likely benefit from being able to know that valid date/time input (both Date and Temporal) is always ASCII-only.

I don't know whether all engines have actually implemented this 2022 grammar change. But it's also a safe bet that real-world usage of this Unicode character is likely minimal. So the web-compat risk seems small.

If this PR is accepted, then I'll follow up with a normative Temporal PR to remove this character from Temporal as well.

FYI @ptomato @gibson042.

justingrant added a commit to justingrant/proposal-temporal that referenced this pull request May 23, 2024
This PR is the Temporal counterpart to
tc39/ecma262#3334.

See that PR for details.

This PR is dependent on that PR's approval.
@michaelficarra michaelficarra added normative change Affects behavior required to correctly evaluate some ECMAScript source text needs consensus This needs committee consensus before it can be eligible to be merged. needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 labels May 23, 2024
@ptomato
Copy link
Contributor

ptomato commented May 23, 2024

FWIW as far as I understand it, this change would not be observable if made in ECMA-262 today, without Temporal. (But it should probably be discussed in plenary anyway.)

@justingrant
Copy link
Contributor Author

Clarifying @ptomato's comment above: this U+2212 character is currently only exposed via Temporal, because the only way an offset can get into Date is via SystemTimeZoneIdentifier which AFAIK is required to be ASCII in all known implementations.

So the current plan is to present a normative Temporal PR in Helsinki to remove U+2212 from the Temporal grammar, and mention as part of this discussion that consensus on that PR also means percolating this grammar change back to 262.

Sound OK?

@anba
Copy link
Contributor

anba commented May 24, 2024

It's normative for ECMA-402, where Intl.DateTimeFormat has been changed to accept offset time zone strings.

@gibson042
Copy link
Contributor

It's normative for ECMA-402, where Intl.DateTimeFormat has been changed to accept offset time zone strings.

concrete example:

const dtf = new Intl.DateTimeFormat("pt", {
  dateStyle: "short",
  timeStyle: "full",
  timeZone: "\u{2212}01:00",
});
dtf.format(new Date("2024-01-01T00:00Z"))
// => "31/12/2023, 23:00:00 GMT-01:00"

@ptomato
Copy link
Contributor

ptomato commented Jun 13, 2024

This normative change reached consensus at the TC39 meeting of 2024-06-12.

@ptomato ptomato added has consensus This has committee consensus. and removed needs consensus This needs committee consensus before it can be eligible to be merged. labels Jun 13, 2024
ptomato pushed a commit to justingrant/proposal-temporal that referenced this pull request Jun 27, 2024
This PR is the Temporal counterpart to
tc39/ecma262#3334.

See that PR for details.

This PR is dependent on that PR's approval.
ptomato added a commit to ptomato/test262 that referenced this pull request Jun 28, 2024
… IDs

These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
ptomato added a commit to ptomato/test262 that referenced this pull request Jun 28, 2024
These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
@ptomato
Copy link
Contributor

ptomato commented Jun 28, 2024

Tests are in tc39/test262#4120. (The first commit specifically contains tests for this PR. The second commit for the companion Temporal PR.)

@ptomato ptomato added has test262 tests and removed needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 labels Jun 28, 2024
@michaelficarra michaelficarra requested a review from a team June 30, 2024 00:34
@Eusinho1985

This comment was marked as spam.

@michaelficarra michaelficarra requested a review from a team July 2, 2024 14:14
@justingrant
Copy link
Contributor Author

I rebased to latest main. Hopefully ready to merge?

@justingrant

This comment was marked as resolved.

@ljharb

This comment was marked as resolved.

@michaelficarra
Copy link
Member

I rebased to latest main. Hopefully ready to merge?

We typically require 2 editor approvals for anything that's not completely trivial.

ptomato added a commit to ptomato/test262 that referenced this pull request Jul 3, 2024
… IDs

These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
ptomato added a commit to ptomato/test262 that referenced this pull request Jul 3, 2024
These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
ptomato added a commit to tc39/test262 that referenced this pull request Jul 3, 2024
… IDs

These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
ptomato added a commit to tc39/test262 that referenced this pull request Jul 3, 2024
These are the test adjustments corresponding to the normative PR
tc39/ecma262#3334 which reached consensus at the
June 2024 TC39 meeting.
ptomato pushed a commit to tc39/proposal-temporal that referenced this pull request Jul 4, 2024
This PR is the Temporal counterpart to
tc39/ecma262#3334.

See that PR for details.

This PR is dependent on that PR's approval.
ptomato pushed a commit to tc39/proposal-temporal that referenced this pull request Jul 4, 2024
This PR is the Temporal counterpart to
tc39/ecma262#3334.

See that PR for details.

This PR is dependent on that PR's approval.
@Eusinho1985

This comment was marked as spam.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jul 16, 2024
…ffsets. r=spidermonkey-reviewers,mgaudet

Also simplify the implementation to use normal string comparison instead of
using character codes.

Changes from:
tc39/ecma262#3334

Differential Revision: https://phabricator.services.mozilla.com/D216275
@michaelficarra michaelficarra added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Jul 17, 2024
Following ISO-8601, tc39#2781 introduced U+2212 (Unicode minus) as an alias
for the regular ASCII minus sign for use in time zone offsets.

There's two new data that lead me to believe that this was a mistake,
and that we should revert this change.

The first is that the newly-released RFC 9557 (the string format
standard that Temporal uses) disallows non-ASCII characters. Its
predecessor RFC 3339 also disallows non-ASCII characters. So
strings that follow the current (since 2022) ECMAScript spec
could be rejected by RFC 9557 clients.

The second new data is feedback from implementers of a Rust version of
Temporal that this single obscure character in the grammar will incur a
performance cost because they must now use Rust strings instead
of plain U8 ASCII data. See
tc39/proposal-temporal#2843 (comment)

This performance issue doesn't seem to be limited to Rust. Any
native implementation would likely benefit from being able to know that
valid date/time input (both Date and Temporal) is always ASCII-only.

I don't know whether all engines have actually implemented this 2022
grammar change. But it's also a safe bet that real-world usage of this
Unicode character is likely minimal. So the web-compat risk seems small.

If this PR is accepted, then we'll follow up with a normative Temporal
PR to remove this character from Temporal as well.
@ljharb ljharb merged commit e7f1e5d into tc39:main Jul 17, 2024
7 checks passed
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this pull request Jul 18, 2024
…ffsets. r=spidermonkey-reviewers,mgaudet

Also simplify the implementation to use normal string comparison instead of
using character codes.

Changes from:
tc39/ecma262#3334

Differential Revision: https://phabricator.services.mozilla.com/D216275
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Jul 18, 2024
…ffsets. r=spidermonkey-reviewers,mgaudet

Also simplify the implementation to use normal string comparison instead of
using character codes.

Changes from:
tc39/ecma262#3334

Differential Revision: https://phabricator.services.mozilla.com/D216275
bakkot added a commit to bakkot/proposal-temporal that referenced this pull request Sep 5, 2024
ptomato pushed a commit to tc39/proposal-temporal that referenced this pull request Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has consensus This has committee consensus. has test262 tests normative change Affects behavior required to correctly evaluate some ECMAScript source text ready to merge Editors believe this PR needs no further reviews, and is ready to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants