Add minutes from January meetings

Author: ptomato

meetings/agenda-minutes-2021-01-07.md

@@ -0,0 +1,80 @@
+# Jan 7, 2021
+
+## Attendees
+- Ujjwal Sharma (USA)
+- Shane F Carr (SFC)
+- Richard Gibson (RGN)
+- Cam Tenny (CJT)
+- Philip Chimento (PFC)
+- Daniel Ehrenberg (DE)
+
+## Agenda
+
+### IETF draft status
+- USA presents the IETF draft.
+- USA: The RFC has deprecated but still allows the use of 2-digit years, it doesn't allow 6-digit years or sub-minute UTC offsets. These are things that we have in Temporal, but of course every change means discussion in the IETF, which might delay our ability to push the change that we care about, which is the time zone and calendar suffixes.
+- RGN: I don't care as much about the more "sugar-y" ones.
+- USA: What we would want to avoid is another separate revision for years.
+- RGN: I don't think RFC 3339 actually allows 2-digit years. The grammar in the appendix might, but that's different.
+- DE: USA already identified 2-digit years as the least important part, so I don't think it's that important to pursue, but it would be strange if 6-digit and negative years weren't included.
+- JGT: I ran into 2-digit years a lot recently when building non-ISO calendars. I think removing it is a good thing to do for the ecosystem, and we could always reverse it if it generates controversy.
+- USA: We can keep it in a separate commit for that purpose.
+- JGT: The other comment I had on the spec is that the grammar talks about durations, but there's no other content about durations. We should have at least negative durations standardized somewhere.
+- USA: Durations are out of scope for RFC 3339.
+- JGT: Should we consider adding them? They should be standardized somewhere.
+- RGN: Are you sure they are not standardized? I thought they were added in the 2019 revision of ISO 8601.
+- USA: They are. The only thing that is not specified anywhere outside of Temporal is the bracketed suffixes. The important thing is that we add the bracketed suffixes, and we may as well add other things that are within the existing scope of the RFC.
+- PFC: I agree with USA, but it is weird that durations are in the grammar.
+- USA: That's my next question, should the grammar be dropped?
+- JGT: I don't see why.
+- RGN: The grammar is kind of a vestigial part of RFC 3339 because the edition of ISO 8601 at the time was not fully characterized, so the appendix was an attempt to formally describe the rest of ISO 8601.
+- PFC: The draft would still have a grammar for the things discussed in the document, but we'd be removing the ISO 8601 grammar in the appendix.
+- USA: Last question is that Ronald Tse brought up that we might shift to a different standards body, CalConnect instead of the IETF, and CalConnect would work with us to move the work into all of the other standards bodies including IETF. He also mentioned that ECMA requires releasing things under a patent-free license whereas IETF doesn't. My concern is delaying things if we choose to move to CalConnect.
+- DE: I thought it would make sense to start this in the IETF but keep CalConnect people in the loop, and eventually move to an ISO standard, but at a lower priority.
+- JGT: I support a more limited scope, looking at the 2019 revision of ISO 8601 my concern would be that we'd never get it ratified within a reasonable time and scope if we went that route.
+- DE: Ronald raised a concern that it wouldn't be possible to develop a royalty-free spec in IETF. To my knowledge IETF develops royalty-free things all the time. Is anyone aware of this concern?
+- USA: The direct quote is "ECMA demands a patent-free license, which IETF work cannot be licensed with"
+- DE: ECMA doesn't review our spec, and ECMA has multiple patent policies. TC39 operates under a royalty-free patent policy, but that's not the same as demanding a patent-free license.
+- USA: Don't we reference BCP47 normatively in ECMA-402? That's also IETF work.
+- RGN: Referencing it is definitely not a problem. You could imagine scenarios where contributing might be a problem, but I'd be surprised.
+- USA: Do we care about whether this update propagates to all standards bodies?
+- RGN: My opinion has been that at least one broad standards body should adopt it for us to proceed. IETF fits the bill. The problem actually stems from Java's introduction of the bracket as a language-specific thing that "infected" the ecosystem. If they had gone through standardization such as IETF then we wouldn't have this problem.
+
+### Progress towards Stage 3
+- PFC: most of the important work includes: the IETF draft, the DurationFormat proposal, questions about calendar localization as well as spec bifurcations. Then there’s a few more minor things associated with the different issues in the milestone. I plan to finish up the spec bifurcation in a day or two.
+- USA: MS2 made a pull request updating the Intl.DurationFormat proposal, I expect to merge it by the end of this week. I have a meeting planned with YMD tomorrow, where we will discuss what we need to move forward to Stage 3. Then I have some things to discuss with people before the 402 monthly meeting, which is next week. I think it should be possible to move forward to Stage 3 for January.
+- JGT: What is the relationship between DurationFormat and RelativeTimeFormat?
+- DE: Integrating durations with RelativeTimeFormat could work, but it can be a separate proposal.
+- JGT: I made a comment a few months ago about how there are several ways to refer to durations linguistically: the period of time, a time relative to now, or relative to a time that is not now.. It's strange that we are separating things between DurationFormat and RelativeTimeFormat.
+- USA: Having signed durations means that they are always relative to a certain point. DurationFormat is for formatting absolute period of time. This can be done in a separate proposal.
+- JGT: But why is a separate DurationFormat API needed at all, when we could extend RelativeTimeFormat to cover all the three use cases. It seems like a lot of work to add and document a new toplevel API.
+- USA: ???
+- DE: I understand and I'm not sure of the answer. I disagree that adding a new toplevel API is that serious though, DurationFormat is pretty superficial. SFC, do you know why we need a separate constructor for DurationFormat?
+- SFC: That's still an open question. There are pros and cons of doing it either way.
+- JGT: Why are we prioritizing the absolute use case when the relative case is probably more common?
+- USA: When you call `toLocaleString()` on a duration, the only interpretation that makes sense is the absolute interpretation. It seems wrong to format an absolute duration with RelativeTimeFormat.
+- JGT: That seems like a purity concern. These three formatting use cases seem really related and it would be odd for developers to have to use a separate formatter for absolute duration formatting.
+- USA: I can bring it up at the 402 meeting and try to come to a conclusion.
+- DE: Can we decouple Intl.DurationFormat going to Stage 3 from Temporal going to Stage 3?
+- PFC: That would involve removing the `Duration.toLocaleString()` method from the Temporal proposal and adding it in the Intl.DurationFormat proposal?
+- DE: There were other `toLocaleString()` methods that didn't do anything smart, and then got updated later. We'd have a non-smart `toLocaleString()` method in 262 and nothing overriding it in 402.
+- JGT: My only concern is a duration formatter that only deals with half the cases.
+- USA: Agreed.
+- DE: What happens with negative durations when formatting them absolute?
+- USA: The sign is ignored.
+
+### Calendars status
+[SFC left.]
+- JGT: I finished the calendars PR yesterday. It contains decent-quality implementations of all the ICU calendars. Doing so exposed a bunch of issues in Temporal, which was the purpose. The two main confusing pieces for people unused to non-Gregorian calendars are leap months, and eras, especially eras that count backwards. These are the places where I'd expect that developers who only know the ISO calendars would trip up. There's also a security risk where people could manipulate software by introducing a calendar to code that didn't expect it. For example, my son changes the date on his iPhone to continue getting free trials of games, and I could see something similar happening with non-ISO calendars.
+  - Leap months: Follow the iCalendar lead and add a string-based month code. Month would still work, but developers familiar with leap months could use the month code.
+  - Eras: Just as with month and month code, there's a reference year for the era.
+  - It's important to be able to reconstitute any of these dates from (ISO) year, month, day, and calendar.
+  - The PR also includes a few other changes that are talked about in separate issues.
+  - The calendars should be in charge of validating the values, not the Temporal abstract operations.
+  - MonthDay is a little weird because in a lunisolar calendar, for example, how do you express a birthday that happens in Adar I?
+  - What fields does `getFields()` export? This is a bit of an open question.
+  - The implementation is hacky, using `formatToParts()`, but it was enough to validate the API.
+- PFC: What sort of feedback would you like first?
+- JGT: I'd like to validate the `monthCode` and `eraYear`, and then we can proceed to split out the other open questions and start merging things.
+- DE: Why `"5L"` and not a numeric month and leap boolean?
+- JGT: Main reason was it's already standardized in iCal. The other reason is that if you split one piece of data (the month) into several properties, that creates problems for developers because they might unwittingly split a date into year, month, and day.

meetings/agenda-minutes-2021-01-14.md

@@ -0,0 +1,110 @@
+# Jan 14, 2021
+
+## Attendees
+
+- Richard Gibson (RGN)
+- Shane F. Carr (SFC)
+- Younies Mahmoud (YMD)
+- Cam Tenny (CJT)
+- Philip Chimento (PFC)
+- Ujjwal Sharma (USA)
+- Justin Grant (JGT)
+- Leo Balter (LEO)
+- Philipp Dunkel (PDL)
+- Manish Goregaokar (MG)
+- Daniel Ehrenberg (DE)
+
+## Agenda
+
+### Stage 3 status
+- PFC: Currently the open questions are the IETF draft, the question of whether DurationFormat stage 3 is a blocker, and the issues that came up during the calendar research that are included on the agenda below.
+
+### Do Temporal Stage 3 and DurationFormat Stage 3 depend on each other?
+- USA: What do others think, should Temporal Stage 3 be blocked on DurationFormat Stage 3? Given the agenda deadline of tomorrow.
+- JGT: If they could be done in parallel, that would be great.
+- LEO: If the sentiment in the group is to advance to Stage 3, even if there are some open questions, it should go on the agenda, but please make sure to include slides with the open questions such as this one.
+- USA: Even if we are dealing with larger questions for DurationFormat, such as "should there be a DurationFormat object or part of RelativeTimeFormat"?
+- PFC: That might be an objection for Stage 3 of DurationFormat, but not Temporal.
+- USA: I agree it doesn't make sense to do DurationFormat before Temporal, but does it make sense to do Temporal before DurationFormat?
+- SFC: Temporal is one of the most expensive proposals to implement that will have been passed by TC39 in a while. Implementations won't have gotten around to implementing `Duration.toLocaleString()` by the time DurationFormat proceeds.
+
+### IETF draft
+- USA: The agreed-upon format for annotations is `[namespace-key-value]`. One-letter namespaces are reserved for BCP 47, so Unicode Consortium gets the namespace "u". If everyone in this call is happy with it, my intention is to finish the draft this week and submit it for adoption.
+- RGN: High-level question, where do you expect the registry of extensions to live? IANA, or Unicode Consortium?
+- USA: I'm copying the process described in BCP 47 for this. They are managed by IANA.
+- RGN: That's the norm for IETF. Since there were other groups involved I wasn't sure, but this is fine. I think it's the best possible outcome.
+- USA: This also allows registering extensions without amending the RFC.
+- RGN: What's the best way to give feedback on the draft?
+- USA: GitHub issues or email.
+- PFC: Do we need to register our calendar key, or is it already registered because it gets the existing `u-ca-` one from BCP 47?
+- USA: Possibly, but given its prior existence I think it's pretty safe.
+
+### DurationFormat issues; `Duration.toLocaleString()`
+- Should we format absolute duration? e.g. “3 days” or “4 days and 5 hours”
+- JGT: If we adopt RelativeTimeFormat, then the default is already decided for us. What's the argument in favour of a separate object?
+- USA: The argument is that it feels weird to have an option to RelativeTimeFormat to format a duration as absolute.
+- YMD: RelativeTimeFormat for relative, DurationFormat for absolute.
+- SFC: It's good to have the output of `toLocaleString()` represent the same concept as the output of `toString()`, which is absolute, disregarding the sign for the moment. The second issue is that RelativeTimeFormat currently does not support formatting of mixed units. That would require an additional proposal, and neither CLDR or ICU currently support it. This feature has been requested, but that's a 2022 time scale feature.
+- JGT: That's the same problem as DurationFormat.
+- SFC: It's a completely different code path.
+- YMD: ???
+- JGT: If you send a negative duration into a localized method, it should not just drop the sign.
+- SFC: Negative durations should not determine the decision. We should optimize for the case of positive durations, and then decide how to handle a negative sign.
+- JGT: Do you think that the localized output for `+PT2H` and `-PT2H` should be the same?
+- SFC: I don't have a strong feeling either way.
+- JGT: That question drives me to think that the default output should be relative.
+- SFC: Why could it not be the absolute output with a minus sign?
+- YMD: I would prefer to agree whether we need the DurationFormat or not, and then decide what to do with negative durations.
+- JGT: I disagree. Given that the three formats exist, spreading them across two separate objects seems wrong.
+
+### Make reference year / day required in MonthDay / YearMonth [#1240](https://github.com/tc39/proposal-temporal/issues/1240) and MonthDay.equals() [#1239](https://github.com/tc39/proposal-temporal/issues/1239)
+- PFC: I think we should close these two given the stage that we're in.
+- JGT: Should the calendar canonicalize the reference year?
+- SFC: You only get these weird cases if you use the constructor. That's just an unfortunate corner of the API and I'm not sure there's a way around it.
+- JGT: How does the calendar choose a reference year given a month and day in `from()`?
+- SFC: First year after 1970?
+- JGT: Many calendars have a 60-year cycle.
+- SFC: Then a different standard, as long as it is consistent. It's OK if the reference year is in the future.
+- PFC: I think this is out of scope for Temporal. The calendar is responsible for picking the reference year.
+- (Some confusion about the term "canonicalize")
+- SFC: In the ISO calendar, if you pass a PlainDate to `PlainYearMonth.from()`, it does discard the year and picks 1972, correct?
+- PFC: Correct.
+- We agree to keep the status quo where the calendar is always responsible for choosing the reference year (except in the type's constructor where it is given exactly), and `from()` always ignores a passed-in `year` field.
+
+### Move validation of fields and options objects into calendar implementations [#1229](https://github.com/tc39/proposal-temporal/issues/1229) / [#1235](https://github.com/tc39/proposal-temporal/issues/1235) / [#1253](https://github.com/tc39/proposal-temporal/issues/1253)
+- PFC: I think that this does meet the bar for changes at this point, so can we agree to go ahead with these?
+- USA: Agreed, if you are using a non-ISO calendar then validation can mean something very different.
+- JGT: One question I had was that we currently access custom fields after the built-in fields, do we have to do that?
+- PFC: If we go ahead with this, then we no longer have to specify it except for the ISO calendar.
+- SFC: Very much agreed to not do pre-processing on the options bag.
+
+### Month / monthCode / monthIndex [#1203](https://github.com/tc39/proposal-temporal/issues/1203)
+- JGT: I have five points that we can discuss before deciding on the names.
+
+1. iCalendar string representation of months
+   - SFC: I'm not comfortable making this decision without Manish here. The other thing not covered by this is Hindu calendar months that may be combined.
+   - RGN: Are you saying that the spec does not accommodate this?
+   - JGT: Correct, you can end up with a month that's month 3 and month 4 combined, and that's not accommodated by the "L" syntax.
+   - RGN: It doesn't specify exactly how, but it does accommodate it. If you merge months 3 and 4, there are multiple ways to represent that; skipping "3" or "4", for one. It's underspecified, but not impossible to accommodate.
+   - JGT: We can safely say that there's no specification for the Hindu calendar.
+   - USA: The Indian national calendar is the one that's supported by ICU.
+   - JGT: All the ICU-supported calendars are fine.
+   - SFC: Maybe JGT, MG, and I can meet to work this out.
+   - JGT: Sounds good. My standpoint is that the name of the month should not matter for the identifier.
+   - SFC: I understand that point of view. The goals of having an identifier for use in formatting and having equality semantics are mutually exclusive.
+
+2. We need both a month code and a month index property
+   - SFC: You've definitely presented use cases for a monotonically increasing month index property. I don't feel strongly about it, but I'm OK to have it.
+
+3. Either the month code or the month index should be able to be used in `from()` and `with()`.
+   - RGN: Is the idea that they'd be passed with the same property name? Or would there be no ambiguity because they would use different property names?
+   - JGT: The latter.
+   - RGN: So by the naming, both would be equally "dis-privileged" or one of them privileged by virtue of having the name `"month"`?
+   - JGT: That's the bikeshed.
+   - PDL: What do you imagine the month code for the ISO calendar to be?
+   - JGT: The string versions of the integers.
+   - PDL: Can we have disambiguation depending on the type?
+   - ???
+
+### `eraYear` [#1231](https://github.com/tc39/proposal-temporal/issues/1231)
+We decide to have an overflow meeting to close out these questions. Since the editors have not reviewed the spec for the January meeting, and SFC is not comfortable proceeding without resolving these questions, we will attempt to go to Stage 3 in the March meeting. We will need to make it extra clear that the spec is ready for review. PDL, DE, PFC stress the need of not changing spec text from our side, and only accepting changes that originate from delegate reviews.