Normative: handle awkward rounding behavior #471

ryzokuken · 2020-07-06T20:51:17Z

Handle awkward rounding behavior when dealing with currencies and the
value of "maximumFractionDigits" is less than cDigits.

Fixes: #239
Test 262 PR: tc39/test262#2707
V8 CL: https://chromium-review.googlesource.com/c/v8/v8/+/2288710

/cc @sffc @littledan

sffc

Thanks!

spec/numberformat.html

littledan

I believe this logic fixes the original issue.

spec/numberformat.html

littledan

I think this version makes sense, but I'd appreciate another look from @anba.

leobalter

I forgot to submit my review to make it public. I'm sorry it took so long. ~~This would also match changes from #472~~ It's similar to #472 but with different goals.

spec/numberformat.html

ryzokuken · 2020-07-09T13:14:48Z

@leobalter fixed! PTAL.

anba

(I haven't yet spend any time in verifying this leads to the expected behaviour. I'll probably just implement it and then see how things work out. 😄)

spec/numberformat.html

anba · 2020-07-09T13:29:41Z

spec/numberformat.html

+            1. Let _mnfdActualDefault_ be _mnfdDefault_.
+          1. Else,
+            1. Set _mxfd_ to ? ToNumber(_mxfd_).
+            1. If _mxfd_ is *NaN*, then throw a *RangeError* exception.


Nit: No "then" in single-line steps.

@leobalter do you feel strongly about this?

Omitting "then" in single-line steps is the normal convention in ECMA-262 and ECMA-402.

@anba is correct

anba · 2020-07-09T13:30:53Z

spec/numberformat.html

+          1. Else,
+            1. Set _mxfd_ to ? ToNumber(_mxfd_).
+            1. If _mxfd_ is *NaN*, then throw a *RangeError* exception.
+            1. Set _mnfdActualDefault_ to min( max( _mxfd_, 0 ), _mnfdDefault_ ).


Add a call to floor, because mnfdActualDefault needs to be an integer.

spec/numberformat.html

ryzokuken · 2020-07-16T06:13:34Z

@anba I think the current version suggested by @sffc is simple enough while being sufficiently good to address your concerns, but could you please take another look?

Also, @leobalter I think your concerns no longer hold anymore, could you review again? Thanks.

anba · 2020-07-20T14:01:39Z

spec/numberformat.html

@@ -30,7 +30,8 @@ <h1>SetNumberFormatDigitOptions ( _intlObj_, _options_, _mnfdDefault_, _mxfdDefa
          1. Set _intlObj_.[[MaximumSignificantDigits]] to _mxsd_.
        1. Else if _mnfd_ is not *undefined* or _mxfd_ is not *undefined*, then
          1. Set _intlObj_.[[RoundingType]] to ~fractionDigits~.
-          1. Let _mnfd_ be ? DefaultNumberOption(_mnfd_, 0, 20, _mnfdDefault_).
+          1. Let _mnfdActualDefault_ be ? min( _mnfdDefault_, DefaultNumberOption(_mxfd_, 0, 20, 20) ).


This will lead to calling ToNumber twice on mxfd, which is observable if mxfd is an object. Do we care about this?

Two nits:

Can you swap the arguments to min so we have min(DNO(...), mnfdDefault)? That way the arguments are consistent with the max call further below.

DefaultNumberOption(_mxfd_, 0, 20, mnfdDefault) instead of DefaultNumberOption(_mxfd_, 0, 20, 20) might be slightly nicer, because than it's directly visible what's the default value for mnfdActualDefault.

I do care about invoking ToNumber on the same value more than once, which should be avoided. I'm also uncomfortable with embedding a potentially-abrupt abstract operation as the parameter of another.

What about something a little more explict/straightforward?

Suggested change

1. Let _mnfdActualDefault_ be ? min( _mnfdDefault_, DefaultNumberOption(_mxfd_, 0, 20, 20) ).

1. Set _specifiedMnfd_ to ? DefaultNumberOption(_mnfd_, 0, 20, *undefined*).

1. Set _specifiedMxfd_ to ? DefaultNumberOption(_mxfd_, 0, 20, *undefined*).

1. If _specifiedMxfd_ is not *undefined*, set _mnfdDefault_ to min(_mnfdDefault_, _specifiedMxfd_).

1. Set _mnfd_ to ! DefaultNumberOption(_specifiedMnfd_, 0, 20, _mnfdDefault_).

1. Set _mxfd_ to ! DefaultNumberOption(_specifiedMxfd_, 0, 20, max(_mxfdDefault_, _mnfd_)).

1. If _mnfd_ is greater than _mxfd_, throw a *RangeError* exception.

(even more so if we replace the second set of DefaultNumberOption with explicit remapping of undefined values)

@gibson042 thanks for the suggestion. Changing my implementation to this produced the expected results, so this should work fine. I'll change the PR to this.

ryzokuken · 2020-07-29T14:43:25Z

@anba @leobalter @gibson042 I have updated both this PR and the V8 CL to Richard's suggested version, which produces the desired result and should also address your remaining comments. Please take another look?

spec/numberformat.html

ryzokuken · 2020-07-30T21:50:35Z

@sffc is this phrasing alright?

spec/annexes.html

sffc · 2020-08-13T04:56:39Z

This has achieved consensus from both TG1 and TG2.

Fix awkward rounding behavior Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding behavior in NumberFormat when formatting a currency with "maximumFractionDigits" set to a value less than 2. Bug: v8:10844 Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5 Refs: tc39/ecma402#471 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#70270}

This reverts commit 40af6ae. Reason for revert: Test262 failures, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2509? Original change's description: > [intl] Impl ECMA402 PR 471 rounding behavior > > Fix awkward rounding behavior > Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding > behavior in NumberFormat when formatting a currency with > "maximumFractionDigits" set to a value less than 2. > > Bug: v8:10844 > Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5 > Refs: tc39/ecma402#471 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70270} TBR=jkummerow@chromium.org,ftang@chromium.org,syg@chromium.org Change-Id: I1cfc05e0e2015ad18c037003c9a9a414e2151e06 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10844 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441549 Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70271}

This is a reland of 40af6ae Change from the rollbacked version - removes the passed test fixed by this PR in test/test262/test262.status TBR=jkummerow@chromium.org Original change's description: > [intl] Impl ECMA402 PR 471 rounding behavior > > Fix awkward rounding behavior > Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding > behavior in NumberFormat when formatting a currency with > "maximumFractionDigits" set to a value less than 2. > > Bug: v8:10844 > Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5 > Refs: tc39/ecma402#471 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70270} Bug: v8:10844 Change-Id: Icfe7363f63d402abccc038e2b8bd78b38d0d9c49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444210 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#70273}

ryzokuken · 2020-10-04T06:44:04Z

This has been landed in V8 and JSC (IIUC). I will rebase on master, so we can merge this soon. @anba @leobalter could you please re-review? Thanks!

Handle awkward rounding behavior when dealing with currencies and the value of "maximumFractionDigits" is less than 2. Fixes: tc39#239

FrankYFTang · 2020-10-04T20:37:52Z

This has been landed in V8 and JSC (IIUC). I will rebase on master, so we can merge this soon. @anba @leobalter could you please re-review? Thanks!

Could you update https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking about the tracking of JSC? Where do you get that info from?

ryzokuken · 2020-10-05T04:37:23Z

@FrankYFTang https://trac.webkit.org/changeset/267500/webkit

FrankYFTang · 2020-10-06T03:13:43Z

thanks

…

On Sun, 4 Oct 2020 at 21:37, Ujjwal Sharma ***@***.***> wrote: @FrankYFTang <https://github.com/FrankYFTang> https://trac.webkit.org/changeset/267500/webkit — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#471 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2N2KLVUNRHEO3AWSL23K3SJFERBANCNFSM4OR6SIIA> .

-- Frank Yung-Fong Tang 譚永鋒 / 🌭🍊 Sr. Software Engineer

…t to be less than the default minimum fraction digits. r=yulia Implements the changes from the "has consensus" PR <tc39/ecma402#471>. The second pair of `DefaultNumberOption()` calls was inlined, because only the fallback case is relevant anyway. Steps 12.d and 12.e from the spec PR were combined into a single `if`-block. That way it also matches step 12.f more closely. Also changed the single `if` steps into an `if-else if` chain, because the steps are mutually exclusive. Depends on D95734 Differential Revision: https://phabricator.services.mozilla.com/D95735

https://bugs.webkit.org/show_bug.cgi?id=216760 Reviewed by Ross Kirsling. JSTests: * stress/intl-numberformat.js: * test262/expectations.yaml: Source/JavaScriptCore: This patch supports new spec change of "handle awkward rounding behavior"[1]. This changes minimumFractionDigits / maximumFractionDigits calculation when the specified ones are less than currency-digits. [1]: tc39/ecma402#471 * runtime/CommonIdentifiers.h: * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::resolvedOptions const): * runtime/IntlNumberFormatInlines.h: (JSC::setNumberFormatDigitOptions): * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::resolvedOptions const): Canonical link: https://commits.webkit.org/229684@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@267500 268f45cc-cd09-0410-ab3c-d52691b4dbfc

ryzokuken · 2021-05-17T10:59:53Z

@sffc after reading into https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#parameters a bit, I feel that the description there still holds and that this PR fixed an unintentional "spec bug" around default value handling. Do you still think we need an MDN edit for this?

sffc · 2021-05-17T20:25:55Z

That's reasonable; thanks. You can add a ➖ to the wiki page then.

# 2021-09-09 ECMA-402 Meeting ## Logistics ### Attendees - Shane Carr - Google i18n (SFC), Co-Moderator - Corey Roy - Salesforce (CJR) - Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison - Thomas Steiner - Google (TOM) - Frank Yung-Fong Tang - Google i18n, V8 (FYT) - Long Ho - (LHO) - Zibi Braniecki - Mozilla (ZB) - Eemeli Aro - Mozilla (EAO) - Greg Tatum - Mozilla (GPT) - Yusuke Suzuki - Apple (YSZ) - Louis-Aimé de Fouquières - Invited Expert (LAF) - Richard Gibson - OpenJS Foundation (RGN) - Myles C. Maxfield - Apple (MCM) ### Standing items - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! - [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) ## Status Updates ### Editor's Update RGN: No updates. ### MessageFormat Working Group RCA: We are working on a middle-ground data model that I hope will unblock the situation. EAO is focused on it, with Stas, Mihai, etc. EAO also put together an initial spec proposal. EAO: I put together a spec outline, not a specific proposal. I think we will be able to merge it later this week. ### Proposal Status Changes https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking FYT: Some more Test262 coverage is done. But we still need help. RCA: I updated browser compat for locale info, documentation for hour cycle, etc. FYT: Do we have an instruction guide about how to update MDN? RCA: The process is moving quickly. It will be easier, though: you can just edit a Markdown file. ## Pull Requests ### Add changes to Annex A Implementation Dependent Behaviour tc39/proposal-intl-locale-info#43 FYT: We added some changes to Appendix A. Does this look good? Do we have consensus to report this to TC39? SFC: +1 RGN: +1 LAF: +1 #### Conclusion Approved ### Change weekInfo to express non-continouse [sic] weekend tc39/proposal-intl-locale-info#44 FYT: Some regions have a non-contiguous weekend. This PR changes the data model to reflect that. LAF: I wonder how this should be understood for all countries. In certain countries, the two "out of business" days may be not contiguous. Should we call it business day and non business day? Because "weekend" might not be the correct terminology. SFC: Is there precedent in CLDR for using "business day" instead of "weekend"? EAO: A quick Google search suggests that Brunei calls these days "weekend". SFC: LAF, please open an issue on the repository to discuss the option name change. SFC: Do we have consensus on the change? LAF: +1 SFC: +1 #### Conclusion Approved ## Proposals and Discussion Topics ### CollationsOfLocale() order tc39/proposal-intl-locale-info#33 SFC: I feel that lists should define their sort order. This is similar to the plural rule strings discussion from a couple of months ago. ZB: I represent the other side. I think developers should not be depending on the order. LAF: (inaudible) RGN: There is guaranteed to be an observable order. The question is whether that order is enforced across implementations, and if so, what should that order be? FYT: Could we return a Set? RGN: Sets also have observable order. SFC: I propose we bring the meta question to TC39-TG1 as a change to the style guide. LAF: +1 about order issue FYT: OK #### Conclusion SFC to make a presentation to TC39-TG1 to establish a best practice in the style guide. ### Define if "ca" Unicode extensions have an effect on Intl.Locale.prototype.weekInfo tc39/proposal-intl-locale-info#30 LAF: My opinion about ISO-8601 is that it is not connected to any locale. Something like Gregorian is connected to a locale, and could carry week info. But ISO-8601 is international. SFC: I think we should consult with CLDR. FYT: This is about the first day of the week and minimal days in the week, not the weekend days. I personally believe that we shouldn't limit the extension; for example, a subdivision could have legislation to change this info. LAF: In my opinion, the impact of saying whether Sunday or Monday is the first day of week, or on the minimal days, is to make a "week calendar": a calendar that lays out days in a week, dated by week number. I can imagine that some countries would like to distribute their own calendar, but I feel that there is a need among people to have the same week numbers. I don't know for sure where the correct place for this concept is. ZB: This is inspired by the mozIntl API. The reason I needed it was for a general calendrical widget, the HTML picker. I think date pickers in general need this, not just calendar layout. I think it is a high-importance API. SFC: I think the calendar subtag, or other subtags like the subdivision, should be taken into account. FYT: I think we should take the whole locale to influence the result. FYT: Do we need to make any changes to the proposal, and if so, what changes are needed? RCA: No strong opinion on that, but concerned by the possible conflict with Temporal #### Conclusion SFC, FYT, and LAF agree that the whole locale (including extension subtags) should influence the weekInfo. FYT to share these notes with Anba and wait for follow-up. ### JS Input Masking 🎭 - Presenter: TOM - Slides: https://goo.gle/ecma-402-js-input-masking - Explainer: https://github.com/tomayac/js-input-masking/blob/main/README.md - JS polyfill: https://github.com/tomayac/js-input-masking-polyfill FYT: Thanks for the discussion. (1) Some parts of what you proposed… if the formats are the same across different regions, it shouldn't be part of Intl. For example, if the ISBN format is the same across regions, it shouldn't be in Intl. (2) Is the name "input masking" correct? (3) A new item to consider is the postcode. That differs a lot around the world. The US has 5-4, India has 6 digits, Canada has special alphabetic rules. (4) It would be good to validate whether a string is a valid input. For example, maybe 13 digits is a valid ISBN, but not 14 digits. (5) A Googler on our team built libphonenumber, and it ended up being their full-time job for a while. TOM: Postcodes are interesting. For validation, that's interesting and useful. Thanks for confirming that it is useful. I think it would make sense to have it in the proposal. EAO: (1) Having built a library like this in the past, you start facing the issue of how to report errors on the input. So it becomes error reporting, but you need to do a best effort at the formatting while also reporting errors in a side channel. (2) Formatting while the string is being edited is just really hard; you should just wait until the field loses focus. TOM: I agree that live updating the field is challenging. What you said about error reporting is interesting. Verification needs a lot of thought. I think it's something most developers probably want. EAO: The biggest question is, how does the side-channel error reporting happen? Because that's an interesting question for a UI component like this. TOM: It seems like it could hook into the mechanism for email verification that we already have. And for on-the-fly formatting, hopefully you could write the formatter so that it can listen to whatever event the developer thinks is the right event. EAO: It's not just about a binary error. It's about providing more context to the error messages. TOM: I think many things can be done. I'm new to this area, so I don't know the precedent. I'm looking for more experience. ZB: Thanks TOM for the presentation. I've worked in this area before. I'm excited about the space, and I have a lot of questions. (1) Parsing is hard. There are a lot of questions here. What happens if they write LTR and RTL? What happens if they type in Arabic numerals? What if they use different kinds of separators? You quickly get into an uncanny valley. (2) You should also think about address formatting, which is like postcode and phone number. Where do you stop? (3) International placeholders is an interesting topic. How do you present a placeholder for a phone number? That really depends on the region. (4) I'm not sure that adding ??? is good for the scope of the spec. (5) About whether this belongs in a spec. It seems like a lot of UX teams will want to customize exactly what the output looks like: they agree on most of the format, but want to change a couple things. There's a good question about how much of this is i18n. (6) And finally, and this is the strongest point, if we were to specify what you are specifying, we would need to back it with a strong library. Because speccing it in ECMA-402 doesn't give us everything. So why not start with writing the foundational library, maybe one that can be used in many different programming languages, and then once you have the library, come back to ECMA-402 and ask whether we should bake it into the browser? That can then help us answer questions about whether the payload is sufficiently high such that it makes sense to ship it in the browser. So basically, I think we should start with a library. I think ECMA-402 is likely not the right place to start. TOM: We could build a library, but we run the risk of making the "15th way of doing things" (in reference to the XKCD comic). Temporal started by making a polyfill, and is now integrating it into the browser. We already have a lot of input masking libraries. RCA: I think this is really useful. (1) I'm concerned that the scope could be very large. (2) I'm concerned about what ZB said; organizations where I've worked have wanted to have their own way of doing things with slightly different interactions and so on. That formatter could be a custom thing for that institution. (3) Another thing is the interoperability with HTML. You could have an input credit card, the pattern, the validation, etc. (4) Highly interactive input fields could slow performance on low-resource devices. TOM: For performance, the obvious tweak would be to do validation on the server. YSZ: I think this is a super important part of the application. (1) Like FYT said, some of this data is not Intl data. (2) Phone validation is very complicated, like ZB said. We need to care about the UI; for example, inputting the credit card should trigger a numeric keyboard rather than an alphabetic keyboard. So it seems like we need <input type="phonenumber"/>. Did you consider starting there? TOM: I thought about that, and I put it in the explainer as an alternative. SFC: In order to avoid the "15th standard" issue, you should approach the industry leader in i18n standards, the Unicode Consortium, about making a working group to establish the industry canonical solution. ECMA-402 looks for prior art, and Unicode is the place we point to most often. This is similar in a way to the MessageFormat Working Group, which was chartered to resolve the competing standards for MessageFormat by bringing all the authors together. TOM: Yeah, reaching out to Unicode and seeing if this has come up before would be a good option. As I've said, I had this in the String prototype, and then realized that this should maybe be Intl. Credit card numbers are generally not Intl, but phone numbers are. So creating that prior art makes sense. ZB: I had discussed this a few years ago with Unicode. But with what SFC said, where there are multiple competing libraries, it means that we don't know what the answer is yet. Once we put it in ECMA-402, we won't be able to change it. When writing a library, we can make it and discard it with something better later. It makes sense that we need a place to assemble expertise from the many organizations. Maybe Unicode is the place. And only after we have that canonical implementation, we can evaluate whether it fits in ECMA-402. MCM: The question about new input forms was raised earlier. Did you list use cases where form input types would NOT be sufficient for, where you need the JS APIs? TOM: In a Node.js server, and you have a CSV file of unformatted phone numbers, you might want to format on the server. So it makes sense to have isomorphic Node and client-side behavior. MCM: Has Node.js said that they need a standard for this? Aren't there already Node modules for this? TOM: Deno is an interesting case. They've started implementing Web APIs like fetch. Programmers are used to the way Web APIs work, and they use them in Deno the way they expect them to work. ### LookupMatcher should retain Unicode extension keywords in DefaultLocale #608 GPT: Seems reasonable to me. EAO: +1 CJR: +1 #### Conclusion OK to move forward with this change; review the final spec text when ready. ### ships the entire payload requirement #588 #### Conclusion FYT to follow up with Anba's suggestions on the Intl Enumeration API to harden the locale data consistency. ### DateTimeFormat fractionalSecondDigits: conflict between MDN and spec #590 GPT: It seems reasonable to match the Temporal behavior. SFC: Do we want to add 4-9 now, or wait until Temporal is more stable? #### Conclusion Seems reasonable to move forward with a spec change. Still some open questions from Anba and SFC. ### Presumptive incompatible change in future edition erroneuosly listed #583 RGN: The spec version is immutable. FYT: Is there a way to publish errata? RGN: I don't think so… I do see some errata on ECMA International, but I don't see references to those errata. SFC: The PR in question is #471. It was merged in January. I don't know why the change to Annex B made it into the edition, but not the normative change to numberformat.html. FYT: The other issue is that we have long tables in the PDF that get cut off. RGN: We're trying to raise funding to generate the PDF by a better mechanism. #### Conclusion Ujjwal to investigate. ### Accept plural forms of unit in Intl.NumberFormat #564 CJR: If we accept the plurals in RelativeTimeFormat, I can see a case for doing that also in NumberFormat. SFC: There are basically 3 approaches. (1), we only accept singular units. (2), we accept plural forms for all units… stripping off the "s"? (3), only special-case duration units like days and hours. EAO: Pluralization for all units is challenging. "inches", "kilometers-per-hour" CJR: Having listened to your explanation, SFC, I agree with your assessment. Doing it on an ad-hoc basis is leading away from consistency. RCA: +1 for not allowing plurals. RGN: I share this opinion. Is there already a reference to CLDR, to prevent this from coming up again? #### Conclusion Stay consistent with CLDR, and add a normative reference to CLDR if there isn't already one.

sffc reviewed Jul 6, 2020

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

ryzokuken force-pushed the numberformat-rounding branch from ba98455 to 5540c42 Compare July 7, 2020 03:35

littledan approved these changes Jul 7, 2020

View reviewed changes

anba requested changes Jul 7, 2020

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

ryzokuken force-pushed the numberformat-rounding branch 2 times, most recently from d752ea9 to 1d0c570 Compare July 7, 2020 14:24

littledan approved these changes Jul 7, 2020

View reviewed changes

leobalter requested changes Jul 8, 2020

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

spec/numberformat.html Outdated Show resolved Hide resolved

anba requested changes Jul 9, 2020

View reviewed changes

sffc reviewed Jul 10, 2020

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

ryzokuken mentioned this pull request Jul 10, 2020

Add "Handle awkward rounding behavior" tc39/agendas#819

Merged

ryzokuken added a commit to ryzokuken/test262 that referenced this pull request Jul 18, 2020

Update tests for tc39/ecma402#471

b832213

ryzokuken mentioned this pull request Jul 18, 2020

Update tests for tc39/ecma402#471 tc39/test262#2707

Merged

anba reviewed Jul 20, 2020

View reviewed changes

nicolo-ribaudo mentioned this pull request Jul 20, 2020

July 2020 babel/proposals#67

Open

sffc reviewed Jul 29, 2020

View reviewed changes

spec/numberformat.html Show resolved Hide resolved

sffc reviewed Aug 7, 2020

View reviewed changes

spec/annexes.html Outdated Show resolved Hide resolved

sffc added has consensus Has consensus from TC39-TG2 has consensus (TG1) Has consensus from TC39-TG1 labels Aug 13, 2020

gibson042 approved these changes Aug 13, 2020

View reviewed changes

leobalter pushed a commit to tc39/test262 that referenced this pull request Aug 13, 2020

Update tests for tc39/ecma402#471 (#2707)

6c3f8cd

sffc approved these changes Aug 14, 2020

View reviewed changes

ryzokuken added 8 commits October 4, 2020 12:15

Normative: handle awkward rounding behavior

c1c59dd

Handle awkward rounding behavior when dealing with currencies and the value of "maximumFractionDigits" is less than 2. Fixes: tc39#239

fixup! Normative: handle awkward rounding behavior

9f0636b

fixup! Normative: handle awkward rounding behavior

46f1e9c

fixup! Normative: handle awkward rounding behavior

d69baa6

fixup! Normative: handle awkward rounding behavior

d90f64e

fixup! Normative: handle awkward rounding behavior

c161258

fixup! Normative: handle awkward rounding behavior

c721f3a

fixup! Normative: handle awkward rounding behavior

58aeac5

ryzokuken force-pushed the numberformat-rounding branch from 96af469 to 58aeac5 Compare October 4, 2020 07:49

leobalter approved these changes Jan 5, 2021

View reviewed changes

leobalter merged commit 15bfdbf into tc39:master Jan 5, 2021

sffc mentioned this pull request Sep 9, 2021

Presumptive incompatible change in future edition erroneuosly listed #583

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: handle awkward rounding behavior #471

Normative: handle awkward rounding behavior #471

ryzokuken commented Jul 6, 2020 •

edited

Loading

sffc left a comment

littledan left a comment

littledan left a comment

leobalter left a comment •

edited

Loading

ryzokuken commented Jul 9, 2020

anba left a comment

anba Jul 9, 2020

ryzokuken Jul 10, 2020

anba Jul 10, 2020

leobalter Jul 10, 2020

anba Jul 9, 2020

ryzokuken commented Jul 16, 2020 •

edited

Loading

anba Jul 20, 2020

gibson042 Jul 20, 2020

ryzokuken Jul 29, 2020

ryzokuken commented Jul 29, 2020

ryzokuken commented Jul 30, 2020 •

edited

Loading

sffc commented Aug 13, 2020

ryzokuken commented Oct 4, 2020

FrankYFTang commented Oct 4, 2020

ryzokuken commented Oct 5, 2020

FrankYFTang commented Oct 6, 2020 via email

ryzokuken commented May 17, 2021

sffc commented May 17, 2021

-. Let _mnfdActualDefault_ be ? min( _mnfdDefault_, DefaultNumberOption(_mxfd_, 0, 20, 20) ).
+. Set _specifiedMnfd_ to ? DefaultNumberOption(_mnfd_, 0, 20, *undefined*).
+. Set _specifiedMxfd_ to ? DefaultNumberOption(_mxfd_, 0, 20, *undefined*).
+. If _specifiedMxfd_ is not *undefined*, set _mnfdDefault_ to min(_mnfdDefault_, _specifiedMxfd_).
+. Set _mnfd_ to ! DefaultNumberOption(_specifiedMnfd_, 0, 20, _mnfdDefault_).
+. Set _mxfd_ to ! DefaultNumberOption(_specifiedMxfd_, 0, 20, max(_mxfdDefault_, _mnfd_)).
+. If _mnfd_ is greater than _mxfd_, throw a *RangeError* exception.

Normative: handle awkward rounding behavior #471

Normative: handle awkward rounding behavior #471

Conversation

ryzokuken commented Jul 6, 2020 • edited Loading

sffc left a comment

Choose a reason for hiding this comment

littledan left a comment

Choose a reason for hiding this comment

littledan left a comment

Choose a reason for hiding this comment

leobalter left a comment • edited Loading

Choose a reason for hiding this comment

ryzokuken commented Jul 9, 2020

anba left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryzokuken commented Jul 16, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryzokuken commented Jul 29, 2020

ryzokuken commented Jul 30, 2020 • edited Loading

sffc commented Aug 13, 2020

ryzokuken commented Oct 4, 2020

FrankYFTang commented Oct 4, 2020

ryzokuken commented Oct 5, 2020

FrankYFTang commented Oct 6, 2020 via email

ryzokuken commented May 17, 2021

sffc commented May 17, 2021

ryzokuken commented Jul 6, 2020 •

edited

Loading

leobalter left a comment •

edited

Loading

ryzokuken commented Jul 16, 2020 •

edited

Loading

ryzokuken commented Jul 30, 2020 •

edited

Loading