Skip to content

Latest commit

 

History

History
116 lines (111 loc) · 10.2 KB

notes-2018-04-20.md

File metadata and controls

116 lines (111 loc) · 10.2 KB
Raw

Hangout code: chromium.org/ecma402

Attendees:

Nebojsa, Daniel, Zibi, ...

Agenda and notes

https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-04-20.md

  1. Administrative issues
    1. Anyone want to help out with cleaning up and publishing notes for this meeting and past meetings?
      • Jungshik - we should just publish what we have.
      • Conclusion - Dan will publish what we have as .md files
    2. Meeting time which is not Friday evening? (Poorly affects at least 3 European attendees)
      • Daniel - we now have more European potential participants. Can we pick another time?
      • Conclusion - let’s use doodle
  2. Questions/issues with existing advanced proposals and APIs
    1. Improve handling of non-Gregorian calendars
      • Add relatedYear option?
      • Make pattern set take calendar into account?
      • Jack - A fuzzer generated this case, and found that Edge and Chrome generated very different results for the Chinese and Dangi (Korean) calendars. There’s some discussion on a Chrome issue, and a 402 issue, and the Edge issue. The spec says that all years are numeric, and there’s just one kind of year and no other concept of year. That seems to not be true for all calendars. How do we handle years, or possibly even other month-like or day-like things, etc
      • Steven - Where is this in the spec?
      • Jungshik - The issue here is that, regardless of the pattern, we only use the base locale, regardless of the calendar. The V8 implementation didn’t follow the spec to the letter; we switched it to follow the spec, but actually Jack is right that if the calendar is different, we should do something which uses the calendar and presents the relatedYear
      • Steven - There are two issues--looking up the pattern based on the calendar, and whether they are all numeric
      • Jack - And there’s the issue of related year vs year name--both, or neither.
      • Zibi - Does this work without formatToParts
      • Jack - It prints something, but it can’t select the right calendar type.
      • Steven - There are two different issues here
      • Jungshik - I am not sure about the wisdom of the two-digit year out of the 60-year cycle; that’s not so useful.
      • Steven - The point of related year is to show something useful, so you can have the emperor era and also 2018. It’s not meant to be the main year.
      • Jungshik - I believe related year in ICU gives the transliteration of the two chinese characters
      • Jack - That’s what the year name gives; the related year shows the Gregorian thing
      • Zibi - Does this scale to other calendars as well?
      • Jungshik - It seems like it’s limited in the spec on purpose
      • Daniel - no, it seems more like a mistake
      • Daniel - Yes Steven, you’re right that there are two unrelated bugs
      • Daniel - Anyone has issue with us making an editorial change?
      • Jack - I was confused about what to expect out of the implementation when you ask for a year in chinese calendar, but not for related year.
      • Daniel - Are we in agreement wrt. This patch? Should we land it and present to the next TC39 meeting?
      • Daniel - One side was already implemented in V8, the other was not yet, but should be pretty simple.
      • Jack - I think it’s good
      • Steven - I think it’s good
      • Conclusion - Land the patch
    2. Locale processing edge case
      • Fix seems clear; go for it?
      • Steve, Zibi - Seems like a bug to be fixed
      • Conclusion - Fix it
    3. Copy PluralCategories in Intl.PluralRules.prototype.resolvedOptions?
      • We had previously resolved to not copy; consider revisiting due to SpiderMonkey implementation?
      • Zibi - I’d prefer us to copy
      • Jack - Edge is creating a new array each time
      • Conclusion - We’ll switch the spec to copy
    4. PartitionNumberPattern treats -0 as 0 (Jack Horton)
    5. Next steps on resolution on grandfathered tags from last meeting?
      • Are ECMA-402 changes needed, or is this only about Intl.Locale?
      • Zibi - Do we want to put Locale processing for ResolveLocale based on Locale?
      • Nciric - This may cause observable due to the additional canonicalization
      • Dan - I don’t think the compatibility impact will be high since this path is already weird and full of bugs
      • Jungshik - Same thing for getCanonicalLocales
      • Conclusion - Make apply new logic for all changes
    6. Intl.Locale issues
  3. ICU tickets to support existing advanced proposals and APIs
    1. API design proposal for Intl.RelativeTimeFormat.prototype.formatToParts accepted with modifications
      • Is anyone interested in implementing? (Small amount of plumbing code)
    2. API design proposal for C API for NumberFormatter accepted with modifications
      • See below under "NumberFormat changes"
    3. unum_formatDoubleForFields will be marked as stable in ICU 61
    4. Dan to write API design proposals for other formatToParts/timezone functions
  4. New proposals
    1. NumberFormat changes, including (a) restructuring the spec, (b) minor changes to behavior, (c) support for measure units, and (d) support for scientific and compact notation.
    2. formatRange/formatRangeToParts (Felipe)
      • Last meeting, settled on the following. Any further thoughts?
        • formatRangeToParts returns a flat array, with a new attribute
        • formatRange/formatRangeToParts as methods on Intl.DateFormat, rather than a new class
      • Next steps
    3. BigInt.prototype.toLocaleString
      • Should we overload Intl.NumberFormat.prototype.format to support BigInt? Or a new method?
      • Conclusion - think more about overloading
  5. Status of existing proposals
    1. Discuss implementation/test development priorities of existing proposals
    2. Ms2ger is working on test262 tests
  6. May TC39 meeting plans
    1. Propose NumberFormat options and formatRange for Stage 1?
    2. Draft presentation
    3. Who wants to deliver the presentation?
  7. Future meetings
    1. Does the two-hour, once a month format still work well?
    2. Feedback about prioritization, running meeting, etc
    3. Is May 18th at 17:15 UTC a good next meeting time?
      • Are we missing out on participation from Asia with these meeting times?
      • Standing request: Find a time which is not Friday evening in Europe
  8. Ad-hoc questions from a v8 engineer (Sathya Gunasekaran I have a spec question: what should be behavior if the options argument to the Intl.Locale constructor is a proxy? Looking at the other intl methods, we explicitly convert the options argument to an ordinary object: https://tc39.github.io/ecma402/#sec-todatetimeoptions (see the unconditional call to ObjectCreate(options)) Should this be done for Intl.Locale too? NumberFormat doesn't seem to do this https://tc39.github.io/ecma402/#sec-initializenumberformat though ..