- Shane Carr - Google i18n (SFC), Co-Moderator
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Daniel Minor - Mozilla (DLM)
- Chris de Almeida - IBM (CDA)
- Yusuke Suzuki - Apple (YSZ)
- Ben Allen - Igalia (BAN)
- Richard Gibson - OpenJS Foundation (RGN)
- Justin Grant - Invited Expert for Temporal (JGT)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Eemeli Aro - Mozilla (EAO)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
USA: (shows issue tracker for 402.) #753, essentially incorporating NumberFormatV2 into 402, hoping to merge this in today / today-ish. #758 is rather important: I half-accidentally presented this to plenary without getting it through this group.
SFC: Normative changes are on the agenda, but I’d like to get normative changes later in the agenda.
USA: Quick update, we’re working on #753, #766 has been a long-standing issue. This editorial PR goes into all of the field and slot names that we have in 402 that are not PascalCased as is expected in 262, so this would be a major editorial improvement that we’ve procrastinated on in the last few years, so please review this as soon as we can – this is a big diff. Let’s get this incorporated, but not necessarily before the cut.
RGN: Looking forward to cutting this release.
USA: #758 which we need to approve, and #709
RGN: One last doubt on #753 about property ordering which we should discuss before merging it in.
USA: This would appear to be a normative change.
USA: Because it’s a stage 4 proposal, the process would be the same, normative or non-normative, a PR that has to be approved by TG2.
SFC: Two normative PRs to discuss, is there anything else we need discussion for in order to unblock the draft? Are there high-level updates before we dive into technical discussions.
USA: Not that I remember. I did post a test version of the current draft that RGN approved, on the ECMA-402 matrix chat.
EAO: Resolved choice of selector, if multiple selectors what to do, we’ve had an outcome we’ve agreed on, approaching consensus on markup elements that we all agree on. That’s all that I can think of that’s relevant at this point.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
SFC: Any other questions re: MessageFormat Working Group? Let’s take a quick look at PR tracking spreadsheet. Still some red crosses on normative PRs, lot of green checks, though. Is nothing missing?
FYT: Question: Wanted to double-check status of spec. Have (several issues) been merged?
SFC: #758 needs to be added to the spreadsheet.
FYT: Enumeration hasn’t merged?
SFC: Need to discuss normative change that RGN brought up.
YSZ: JSC will be first implementation of proposal. Thank you for proposing this – it’s a huge improvement.
SFC: 1st, change that RGN suggested on NFv3. Section of spec in question is regarding resolvedOptions. The way this work is we read from Table 1 for everything but rounding type, because rounding priority needs to be calculated later.
RGN: Proposed change: store it in a slot, read it from the table.
SFC: There are cases where if the rounding priority isn’t specified, compact notation doesn’t output either fractionalDigits or significantDigits. In order to maintain invariant we have to output the higher precision rounding type when compact notation is used. Round-tripping rounding priority is not sufficient.
RGN: No, I’m saying introduce a new slot, [[RoundingPriority]], which only the table in resolvedOption would use. Take these special steps and move them into initialization.
FYT: I feel this should be approached post-ship in NFv4. What RGN suggests may work, but because of the deadline and consensus is stage 4, whatever you suggest has a risk of exposing some additional bug that under the pressure of the schedule may cause problems. Suggestion: merge as-is and look at this carefully post-merge.
RGN: Let me clarify: I don’t like it, but I can live with it. I approved the PR.
FYT: Let’s open a ticket and talk about that – but timing-wise we should talk about it post-merge. I don’t like it either, but let’s do it without time pressure so that we can do it correctly.
SFC: I’m in a conflict of interest since I’m the author and also the convenor. Procedurally, we don’t have a PR to make this change, and as a group in order to form consensus we need to review/approve the PR and present to TG1, and there’s not really a runway for that right now. Would rather not hold up stage 4 proposal on this detail, since browsers have already shipped it. Agree with FYT that we should discuss it post-merge.
RGN: I’ve heard that browsers have shipped with it this way, I want to know what that means. I don’t see ordering-of-properties coverage in test262.
FYT: Why is this related to ordering?
SFC: It’s the last one inserted in the record.
RGN: The reason why this is normative is because the ordering of properties is observable.
SFC: What’s the right way to observe that?
RGN: Object.entries if you want.
FYT: Since it’s already inserted at the end, there’s no observable change at this point.
SFC: We could put it at the end of table 1 and make it editorial.
RGN: Editorial change that alters the table and preserves the output. But the output is part of what I don’t like. Why is roundingPriority stuck at the end rather than other rounding-related fields? This PR is adding the four at the end, but in a bizarre order.
SFC: Would like to go back to the ask: I think this discussion is not something we should be having right now for procedural reasons rather than technical reasons.
USA: Couple of points: 1st, I do agree with RGN that this is awkward. It would be slightly nicer, at least, to have all the related options together. Easier to read, easier to process. But, this is not the most common way to access resolvedOptions, the more common is for people to either destructure some properties or to do object access, situations where order doesn’t come into play. Third, the fact that this is a stage 4 proposal then irrespectively we’ll have to go through the same process pre-merge or post-merge, even though it’s not part of the spec yet. If we merge as-is, then I’d be very much in support of this normative change.
SFC: Concrete request: land the PR and then follow up very shortly after with another PR. RGN, if you make that PR by the end of the call, we could even discuss it in this call.
RGN: Minor issue, PR has my approval.
SFC: Let’s push the merge button.
USA: We should squash first…
SFC: I’ll let editors do the editor job.
Revisit the standalone PR when ready.
SFC: #709, we previously discussed this in October. Conclusion in October was we wanted to see test262 change to see impact in test262. Do we have that data as requested? Yes. Impact on test262: Normally we were creating properties twice, now only creating once, looks like that changed in a few different places. Oddly, only certain fields were duplicated.
FYT: only day and time-related options.
SFC: Let’s bring this back up for discussion and see if we can reach consensus.
RGN: Should be good for us, but it has not been raised to TG1.
USA: I wanted that to be the case, went through all the presentations I’ve given in the last year or so. Seems that for better or for worse it hasn’t been presented to TG1 in recent pass. I think the best thing would be to present it at next plenary.
FYT: Years ago we had an issue with the test and had to read it twice. In support of changing it, implemented in V8, I support the proposal but I oppose including it in ES 2023. To agree on that we need to go to plenary, and in the meantime I’ll update V8 to do thi, we don’t have time for ES23.
USA: Seconding what FYT said. We’ve only really unconditionally approved it as TG2 today, technically this was blocked already from being approved by TG1.
SFC: It was an oversight – it could have been included in either January or March.
FYT: I don’t think the PR was ready by that time.
RGN: I think it was just ready for March, but we didn’t get it on the agenda. Definitely not ready for January.
Do we have TG2 “consensus”, where consensus is in quotes. Do we have the agreement of everyone in call that we want to send this to TG1 with TG2’s understanding that this is a good change?
RGN: +1
USA: +1
FYT: +1
EAO: +1
YSZ: +1
TG2 agreement.
FYT: Issue we’ve had for a long time: we have h11, h12, h23, h24, but no one’s using h24. Our algorithm is weird/behavior is weird, I propose we change it. Handling by adding two internal slot for localeData to remember the preference, and based on that derive the default hourCycle on whether h12 is turned off, doesn’t change when h12 is absent, only when it’s true/false. Data-driven, rather than decided by logic inside ECMA-402. US is h11, in Europe, mostly h23, in Japan h12. No one really using h24.
SFC: I think that Frank’s most recent proposal gives the most flexibility, because data-driven. The current spec is too algorithmic, in that it tries to match the hourCycle – doesn’t make sense to say “if h23, prefer h11.” New algorithm is much better. Good from my perspective.
USA: Nit: Now that we are going through the spec and changing the different slots/fields to be PascalCased, can we change the new fields that are introduced in this one to be PascalCased from the start?
FYT: Sure
USA: Thank you!
USA: I support this.
SFC: Conditional on casing of slot?
USA: Conditional support is too strong, either way we’ll have to make this editorial change right now or later.
SFC: If we agree on the normative change, the editorial change can be done either first or second. Any other questions or concerns?
RGN: Do we have test262 ready?
FYT: Nope
SFC: Would you like to see test262 before giving TG2 conditional approval.
RGN: No, we can approve it now but it won’t merge until test262 ready.
FYT: Thought it was the other way around?
RGN: No, the PR has to already be open – we need a PR against test262 before we merge it here, then we merge it here, then we merge test262.
FYT: I thought test262 was only accepting tests against merged-in rather than PR
RGN: Sequence: normative PR is opened, test262 PR is opened, normative merges, test262 merges.
FYT: Ah, that makes sense. As long as people agree, I can work on adding tests.
RGN: You have agreement.
FYT: It might be tricky, there’s no observable aspect of the test that can be tested against.
RGN: Feel free to reach out to matrix channel for test262. I18n ones are always tricky. I believe there is probably some testable aspect.
FYT: Action item: add test. Consensus that we’ll present at TG1 in May?
SFC: I think for both of these.
TG2 agreement
https://github.com/FrankYFTang/intl-zoneddatetimeformat
SFC: I sent out an email with a large list of topics. We already did #753. We have several DurationFormat things to discuss, take break, then after break see what time we have for other things. Agenda sound good?
JGT: I need to leave early today, could we talk about ZonedDateTime first?
SFC: With a timebox of 15 minute
FYT: I have a stage 0 proposal that I’d like to go to stage 1 in May. The basic idea is that three weeks, four weeks ago we had discussion in the Temporal working group that concluded that it’s way too hard to pass in the ZonedDateTime because of conflict with time zone. Conclusion: ZonedDateTime will work in Temporal, but DTF is not going to take ZonedDateTime from Temporal, which I believe is the right thing to do because it’s way too complicated to make DTF into ZDT, because it has additional info that Date never has (time zone). This means we have two issues: is there no way you can have an object and use it consistently to format a ZDT? Second thing: no way to format a range or parts of ZDT. No object, no range, no part. Therefore, the stage 0 proposal is to add a new Intl object very similar to DTF which can only handle formatting ZDT. Stage 1 proposal, so we don’t need a lot of detail. What the spec text does is similar to DTF. Into ZonedDateTimeFormat constructor, pass in options. Lot of detail not filled in, similar to DateTimeFormat object, doesn’t take time zone. Cannot return a time zone.
Look at properties of ZDT, you have something similar to Temporal, because you have a ZDT you can create a DTF. DTF is different from ZDT in that it internally has ZDT, similar to Temporal you can create an object by passing a tz in, because of that we also add additional function to DTF to have toZDT, this one creates the new object from what’s in it but without a tz. Either try to make it very close to Temporal framework, but in order to advance to stage 1 those details don’t need to be discussed, the key thing is whether to have a new object. The scope still needs to be discussed.
SFC: Thanks for putting this proposal together. I think for the purposes of stage 1 this is a worthy problem space to explore. How do we have a configurable object to format ZDT that come from Temporal. I won’t give an opinion on the shape of the proposal, will let others speak first.
EAO: Much the same as Shane I think this is an entirely valid problem space to find a solution in, not convinced that Int.ZonedDateTimeFormatter is the right solution, but we should find a solution.
USA: I wanted to comment about the shape of the proposal. Before I reduced actively working on spec side of Temporal I remember working through some of this design for DTF, most of it predates the existence of ZDT to begin with. Even then it was a complex problem space, to take an object that has been designed keeping in mind Date and all the trappings of it, and extending it to all of the differently shaped Temporal objects. We did our best to make sure it worked, but I agree that the introduction of an attached tz with it complicates thing to the extent that it’s probably better to design something from scratch. The DTF to ZDT formatter is a new concept, I’m not against the idea in principle, but we don’t necessarily have to do it. For example: just do .resolvedOptions() and throwing that into the new constructor. If we do this, we have to make sure we do it well.
FYT: The precedent in Temporal itself?
USA: There is precedent in Temporal but not Intl for converting one formatter to another.
SFC: Weighing in on design direction: one thig that’s a little weird is the naming, because ZDTF doesn’t actually have a time zone. It formats, but no time zone. DTF is the opposite. In terms of having separate objects, one regret I have with Temporal is that we didn’t have a thorough discussion of the whole mosaic of exactly how we make formatters for Temporal objects. We had a discussion with a small group of Temporal champions where we made the proposal, but didn’t have a full discussion with this group. This got to stage 3 without thorough review from TG2 people, which is one regret I have. One option was have separate formatters for each Temporal type. We have a special formatter for one Temporal type but not others. This is an acceptable end-state, but we should discuss this more thoroughly. Since already shipped in some browsers, not sure there’s room to take a bigger-picture look on this, PlainMonthDay, and other things – do we need an Intl.PlainFormat? Maybe FYT has ideas at stage 1 to address that side of the picture. Good for stage 1, though.
USA: Everything that SFC said, +1. Commented in pass that the 402 part of Temporal was bigger than median 402 proposal, oversight that we didn’t have. Something I thought: everything can be done with DTF except for ZDT because it has the problem in that it includes a time zone, which the formatter does as well. Clarifying question for FYT: does this problem not exist for calendars?
FYT: It is a problem. I prefer we take everything everything out of Temporal, out of DTF, but that’s already stage 3, Temporal went to stage 3 too early. Don’t have a strong reason to go to Temporal to say “get those things out of DTF.”
USA: If we’re going to do a second DateTimeFormatter, why not do a second formatter that works for all Temporal objects instead? A new DTF (different name of course) that works on all Temporal objects, we can do away with old API choices. Big ergonomic cost to having separate formatter.
FYT: Yes, but I don’t want to go to Temporal and start a fight about that.
EAO: Do I understand right that ZDT objects can’t be formatted?
SFC: Only through a .toLocaleString.
SFC: Regarding calendars vs time zones, this was thoroughly discussed among Temporal champions and it is not a problem for Calendars because Calendars in DTF are always in human calendars, but calendars in Temporal are usually ISO-8601, which is losslessly converted to the human calendar upon formatting. This is just fundamentally different for time zones because of the data model.
SFC: I would be open to someone opening a PR to do what we did with ZDT to the other objects: don't allow them as arguments to DTF.prototype.format, but still allow toLocaleString. Remove things and add them later. If everything starts with .toLocaleString at least they’re formattable day-1. Not saying anything binding, but postulating that if someone wants to make a PR it would be something worth discussing, since it’s purely subtractive.
USA: I would not consider it totally subtractive in that we’re breaking, to some extent, the Temporal proposal into the formatters part and the data model / arithmetic.
FYT: It’s subtractive because we can accept some Temporal objects, we’re now saying we won’t accept them in stage 3 spec. I’d love for it to happen, but.
USA: I can volunteer to assist with doing the work of talking with everyone.
SFC: Separate discussion than proposal, we’re at end of timebox.
JGT: I think it’s a good discussion to have, my original opinion is still the same (using DTF for everything isn’t bad). I wouldn’t necessarily throw the baby out of the bathwater for that kind of simple solution. Good to discuss, lots of interesting options.
YSZ: +1
SFC: +1, I’ve seen some other +1s.
Stage 1 approval from TG2
fractionalDigits, (||milli|micro|nano)secondsStyle impact to number of fractional digits while style: "digital" #139
tc39/proposal-intl-duration-format#139
USA: First, #139. FYT opened this issue recently. The problem is that digital is an outlier in everything. There were a number of previous designs that hit this flaw and couldn’t handle it. FYT has noted that for sub-second units, in the digital style the display is controlled by fractionalDigits. The amount of information displayed /granularity of output is controlled by fractionalDigits. There are other options that (microsecondDisplay, millisecondDisplay) that control whether it’s always displayed or only when not 0. As it turns out, these don’t go well together. As fractionalDigits needs to exist for the three units, for the style these options that already exist because of making sense for other underlying styles don’t make sense. The simplest solution is to not accept explicitly setting these options.
FYT: I don’t think that’s the right way to phrase it. It is only a problem if it is "always". "auto" is not a problem. There's no conflict if it is "auto".
USA: Not a problem if it doesn’t say anything.
FYT: If you say “auto” and fractionalDigits, it won’t be a problem. When set to “always”, it’s conflicting.
USA: Setting “auto” doesn’t do anything either, but not unexpected what the final output. Setting one of these three to “always” when style is digital is problematic, precisely why fractionalDigits exists, proposal is to disallow this set of options. So basically if you set millli, micro, or nano to “always”, it will throw a RangeError. Change that produces least user confusion, rather than failing silently.
SFC: Clarifying: the ill-defined condition is when there’s a field whose style is numeric and a parent in the fractional part. Numeric used in seconds and above, totally valid to have display “always”, only ill-defined in fractional part.
USA: By default set to “always” in seconds, minutes, hour.
FYT: Repeat again?
USA: That has nothing to do with sub-second units.
FYT: The issue is that’s why it’s not set to default.
USA: If style is undefined and base time is digital, displayDefault is set to “auto”. Otherwise…
SFC: There’s a separate issue that FYT has a PR open on, that this section of the spec is very confusing.
FYT: I find this issue when we try to look at output when style is digital, but really it’s about whether that particular field is numeric or not.
USA: That is still the fraction. When you’re displaying the subseconds as a fraction is when you get this issue.
FYT: As long as in that 3 field, they are set to "always", we have this problem. style: "digital" is one way to lead to this, but it is not the only way.
USA: To clarify, for milliseconds, microseconds, nanoseconds, if any of them both have the style as numeric and the display as always, we should throw.
SFC: Is there a reviewable PR for this? What we should ask the group right now is do we like the PR? Can we get agreement in TG2?
USA: This is GetDurationUnitOptions, where we pass in the units and we do the final resolving of them. Before they’re resolved, if the resolved options were style: “numeric” and display “always” and the unit is sub-seconds, we should throw.
SFC: Want to get feedback, especially from YSZ as first implementor for all DurationFormat proposals today.
YSZ: I’d like to compare the implementation and other things, explore and construct my feedback.
SFC: Any other feedback on whether this change is good from an ergonomics POV? Explicit voices of support for this proposal? I’m personally okay with it – I think it’s a positive change overall. Given that the proposal is stage 3, any change we make needs to make a high bar. Not sure if this change meets that bar, but it’s a pretty harmless one. I defer to YSZ on this as someone who’s actually implemented it. On the edge w/r/t whether this is justifiable as stage 3.
USA: I agree, we should wait for YSZ to analyze this. At the same time, this was clearly a bad interaction kind of a bug, because when we added fractionalDigits it was with the explicit intent of controlling how these units are displayed in numeric style without noting that the other way of doing it for these cases doesn’t interact well, since it can’t actually control the display in that situation. These things become obvious only while implementing them.
SFC: Could be the case that if people need more time…
USA: That would be good, we could take this discussion async. Talking a bit more would be nice.
EAO: I think this is a sufficiently corner-case situation that we’re trying to fix that I’d feel comfortable making the change at this time. +1
YSZ: I think it makes sense, and I support this change. +1.
FYT: Not trying to influence people: let me explain why I proposed PR. If we do not do this, the consequence is that the user will scratch their heads about what the formatting means – if we don’t throw, we go into this mode that would always display nanosecond and always not display nanosecond.
SFC: Justified – corner case, but justifiable one that has a papercut for ergonomics/usability of the API. I think that’s 5 +1s, which seems to be TG2 agreement.
USA: We have time before next plenary to discuss async.
FYT: Do we need a test262 test for this? Is it required?
SFC: it’s not required, but we should definitely hav eit .
EAO: Noting that in issue #65 I proposed adding a new option fractionalUnits that fractionalDigits could then target. That’s a separate concern. If we add this restriction now, there is a way to remove it later / allow a workaround.
Approval from TG2
tc39/proposal-intl-duration-format#144
SFC: The issue here is one line of code. Currently fractionalSecondsDigits defaults to 0, which means these fields are hidden by default, unlike the behavior of any other part of Intl.DTF, which displays fields by default. This could be the case even if your duration is only milliseconds and smaller, you’ll get a render of 0. My concern is that it’s against the grain of the design of the proposal to hide fields by default. Instead of by default setting maxFrac to 0, set it to 0. I want to make sure that this is a problem before discussing solution.
FYT: According to current spec, what is the output?
SFC: 0:00:01. I think it should be 0:00:01.23.
USA: Current output is 0:00:01
USA: To add context to the problem, DF as designed has one option for controlling fractions. Originally default was undefined. Effect was that when fed into the NumberFormat this would pass in undefined as both minimum and maximum fractional digits. So it did work, but we uncovered that and changed the default value to 0 without realizing that this would be a side effect. This is what Anba talks about in other issue: we should change the output. One way to deal with that is to split fractionalDigits into minimum and maximum to get more clarity.
SFC: I want to establish the problem side before discussing the solution part. Don’t want to get held up in solution before we establish there’s a problem.
FYT: We should also consider the condition that if you have the exact same thing, but then you have not millisecond but microsecond 230.
SFC: Output will be correct, but with additional 0s on fractional part. Output would be 0:00:01.0023.
FYT: What I worry about is that some of the styles are short and you have a microsecond which is short too, but then you have nanosecond with style numeric. In theory you should only output three digits at much. I don’t want to see more than 3 digits in that case.
SFC: Interesting problem, but we don’t allow fractional nanoseconds. Fractional microsecond is only allowed up to integer number of nanoseconds.
FYT: Should not be more than 3 digits?
SFC: Correct. Exact integer arithmetic going on here.
FYT: I support it – it doesn’t make sense to have 0:00:01. It’s an issue we need to solve.
SFC: Anyone else want to voice support/opposition to this being a problem we need to solve. If so, we have two potential solutions, one smaller, one larger.
SFC: Let’s look at the proposed solutions, then. One is don’t change anything, but if there’s a problem we need to change something and it will be normative. Option 2, all we do is change default maximumFractionDigits to 9, but it behaves the same way if maximumFractionDigits specified. Since it’s stage 3 I’m loathe to make big changes – this is a small change that can be made with a scalpel. Larger change is #3, currently we have fractionalDigits in options bag for Intl.DurationFormats. Remove option bag and add setters as in Intl.NumberFormat. A little more user flexibility on how numbers are displayed, the downside is that it’s stage 3. The other reason we have fractionalDigits as the name is that it’s more consistent with toString() on Temporal. It may be the case that we decide that fractionalDigits is something we want and it’s stage 3, so we go with option 2 instead of option 3. I’m not going to advocate for option 3, but if the group prefers it we should go with it.
USA: I’ll make a case for option 3 or a potential option 4. Option 1 is not an option since the issue is same as classified by Anba: current output is not right. I’m against option 2, because will hardcode within constructor to have maxFractionalDigits as 9, but the default will show up as 0 – potential user confusion where you don’t pass in fractionalDigits, you see minimumFractionDigits is 0 but don’t see that maximumFractionDigits is 9. Too quick to judge – we could have both of them and they could resolve to different results and that’s good. Option 4 is sort of like option 1, which is where we go back to where we came from. If it works for all of us, we could set the default resolvedValue of fractionalDigits to undefined, this way it doesn’t just work, but you don’t see user confusion – fractionalDigits resolve to nothing, because you didn’t supply anything. I’m happy with 3 or 4, 1 or 2 have issues.
FYT: Clarification question: For 2, what is the resolvedOptions output? What field?
USA: fractionalDigits
FYT: Current option only return fractionalDigits to 0. In option 2, what happens?
SFC: Rephrasing what USA said: If we went with 2 or 3, resolvedOptions would still have fractionalDigits set to 0, which is just wrong. Option 4 is a good approach – we try our best to maintain the invariant that resolvedOptions can create an object with the same behavior. If fractionalDigits is undefined we get min 0 max 9, if defined we set min and max to that value.
USA: Basically my concern is that 2, we are resolving fractionalDigits but essentially what fractionalDigits represents is minimumFractionDigits. maximumFractionDigits resolved from 9, but you can’t see it in options.
FYT: So you would not return the maximum, user has no idea what the maximum is.
USA: That is my understanding of option 2. We’re changing the behavior of the underlying NF but not how fractionalDigits is displayed to the user. At this point, fractionalDigits only really applies to minimum.
FYT: So, for option 4, you set fractionalDigits to undefined, but the users don't know what minimum or maximum.
USA: It is what ever the implementation needs. In fact, there’s no minimum and maximum in this situation. It’s the amount of decimal spaces needed to represent that information.
FYT: In number 4, your default of fractionalDigits is undefined. So what is the output?
USA: The output is what Shane suggested – 0:00:01.23.
FYT: And what is resolvedOptions?
USA: fractionalDigits = undefined. I'm starting to like option 4 even more. We're back to a single fractionalDigits setting. If it’s undefined, the underlying NumberFormat will have the biggest range – min: 0, max: 9. You’ll see 6 fractional digits, 3 if you have milliseconds. However many the implementation needs.
FYT: Will user have a way to query?
USA: Let’s change undefined to auto, that’s maybe option 5. We include a string option “auto” which will represent this.
FYT: User cannot know minimum or maximum?
USA: Yes, because they didn’t set anything. It’s just whatever’s necessary to display the entire information. It is quite valid, since as SFC pointed out that’s the behavior in general of DurationFormat – it shows you all the info it can, and goes to great length to avoid hiding information unless that info is at the end in fractional seconds. It’s the same here, except if you don’t set anything.
SFC: Interrupt: we still have more DurationFormat issues to discuss. Resolve: did we agree that it’s a problem, and if we do agree, can we express a preference between 4 and 5? I would like to go with 4 because I want to solve this with a scalpel, not a hammer. Easy to implement – thinking of YSZ here, because I don’t want to make a big disruption to implementations. Option 4 is a concrete way to move forward.
EAO: 4 is fine.
USA: Can I add? I’m not sure exactly which version YSZ has implemented, but from this comment it’s clear that 4 is the more convenient option because it was the status quo until recently.
SFC: Clarification: earlier version had undefined which inherited min/max of 3 from NF. min/max of 9 is what we need – slightly different from old version of proposal. Better version of old version of proposal. YSZ: temperature check?
YSZ: I’m looking into the implementation: I’ll comment once I find something. I think that it makes sense (option 4), but I’ll need some time.
SFC: Pending YSZ and FYT feedback,
FYT: I’m positive for 4, but will need to look at proposed PR carefully. I think the chance there will be problems is small. I support it, but would like to see PR.
SFC: Good conclusion: group is generally positive toward 4, but we should see a PR before formal agreement. We have one more meeting before next TG1.
TG2 positive toward option 4; pending a PR.
tc39/proposal-intl-duration-format#134
FYT: USA, quick question: did ecma402 make change to make sure ListFormat will take list of things to make your PR work? Used to be a problem that this didn’t work because ListFormat had no way to take the option.
USA: RGN could clarify, but not to my knowledge. ListFormat takes a list of strings, which is not what we’re providing here. Which means we need to change this format to take non-strings, or we need to change the proposal to work with that .
SFC: editorial stuff we don’t need to discuss, but quickly: Some big editorial things open. Two competing table cleanups. Focus rest of 11 minutes on last meeting discussion topics from Anba. We need #146 and #149. #149 real fast.
USA: It’s a duplicate.
FYT: We don’t need to discuss this, right?
USA: If we solve the other issue, it’s solved.
SFC: PR #146 is the last one we need to discuss.
tc39/proposal-intl-duration-format#146
USA: This is another kind of problem in the same vein, when talking about roundingMode of NumberFormat. When we’re creating a NumberFormat for the fraction, we should always truncate, but this is not explicitly set. This is a bug or oversight in the same vein. I support it.
SFC: Another normative change that may impact YSZ’s implementation, but it’s a small change.
YSZ: LGTM.
SFC: Additional feed back from someone like EAO?
EAO: No real opinion on this one.
SFC: Issue here is that if you have a duration like 1 second and 550 milliseconds, but you have fractionDigits = 0, should we round to 1 second or 2 seconds? I would say normally when dealing with time we truncate. This might be something that JGT might have an opinion in?
FYT: What’s the default?
SFC: Half-expand.
RGN: Rounding up could propagate through all of htem.
JGT: Not rounding up is appropriate for time units. You don’t get to say “10 minutes” until you pass 10 minutes.
FYT: The big problem is 1 second 999 ms. If you round it won’t be 2 seconds, it’ll be 1.
USA: Correct. If fractionalDigits is set in a way such that the actual value isn’t included, we might accidentally round up.
SFC: 59 sec 999 ms – we’ve consistently avoided in NF rounding that up. The case that RGN brought up is stronger.
FYT: No possibility of negative value here, right?
SFC: No, maybe. I say trunc because it’ll work in either case, rather than floor.
FYT: I support it.
JGT: +1
SFC: This is mergable only after NFv3 is landed, since trunc is newly landed. But that should happen in a matter of seconds.
SFC +1 from JGT, SFC, USA, FYT – agreement on this one?
FYT: #145?
SFC: That’s a duplicate.
FYT: Anything that landed we need consensus to go to TG1?
USA: Before TG1 we should get consensus on all these things. As Shane pointed out, this table cleanup is editorial, has two competing PRs, same for partitionDurationFormatToParts.
FYT: Unit omission may be normative, can’t make call re: normative/editorial.
USA: I believe it’s editorial, doesn’t change, it’s a spec bug.
SFC: Spec bugs are a gray area, but it doesn’t affect user-observable behavior.
USA: Doesn’t change that unit property is set.
FYT: In a sense it selects a different number of records.
SFC: I see what you mean, but it still seems like a typo in the spec.
USA: Behavior was still the same, some parts have units, some don’t.
SFC: We don’t have time for slides, will present next time, would appreciate people review those slides, will include them in summary email, you can give comments in the slide deck. Out of time but will leave meeting open if FYT/USA/ others want to talk about editorial issues.
FYT: I want to make sure that anything we have merged into spec but don’t have clear consensus in TG1 or here so that we can present in May to have official consensus.
SFC: Hopefully we haven’t merged in anything normative that we don’t have consensus in. USA/BAN, can we review these to make sure we have them right from a process POV?
TG2 agreement.