Correct meeting notes (#759)

Frank noted some differences between the meeting notes and my understanding of the discussion, so this change corrects the notes.

meetings/notes-2023-03-09.md

@@ -101,13 +101,15 @@ https://docs.google.com/presentation/d/1b74GI-zHrG0wDzmwFs_yPWRli24KyVUNx3GeZt8J
 
 https://github.com/tc39/proposal-temporal/pull/2479
 
-JGT: Today in ECMAScript no ECMAScript object carries a timezone with it. With TemporalDateTime, this object carries a timezone, and there’s a potential conflict. The goal for solving this is to recognize that a very large percentage of Intl.DateTime objects have no timezone at all. Assumption is that we can create a DateTIme object and format it with at ZoneDateTime timezone and have it give the ZoneDateTime time. 
+JGT: Today in ECMAScript no ECMAScript object carries a timezone with it. With TemporalDateTime, this object carries a timezone, and there’s a potential conflict. The goal for solving this is to recognize that a very large percentage of Intl.DateTimeFormat objects were not created with an explicit `timeZone` option. Assumption is that we can create a DateTimeFormat object and format it with at ZoneDateTime timezone and have it give the ZoneDateTime time zone. 
 
-What we’re considering is: what happens if the DateTime object has a time zone as well? There’s a potential conflict between DateTime and ZoneDateTime. Option: if the DateTime object has a timezone, throw. We try not to have data-driven exceptions in Temporal, we try to throw based on the shapes of the inputs rather than the data in those inputs. 
+What we’re considering is: what happens if the DateTimeFormat object has a time zone as well? There’s a potential conflict between DateTimeFormat and ZoneDateTime. Option: if the DateTimeFormat object has a timezone, throw. We try not to have data-driven exceptions in Temporal, we try to throw based on the shapes of the inputs rather than the data in those inputs.
 
-SFC: This isn’t my first-choice approach, but it seems to be closest to a consensus response among Temporal champions. DateTime objects have two states: one where there is an explicit timezone, and one where there isn’t, and recording this state somewhere. Requires change to Intl.DateTimeFormat data model. 
+SFC: This isn’t my first-choice approach, but it seems to be closest to a consensus response among Temporal champions. The proposed change is that DateTimeFormat objects would have two states: one where there is an explicit timezone, and one where there isn’t, and recording this state somewhere. Requires a one-bit change to Intl.DateTimeFormat data model.
 
-JGT: Note that Date.toLocaleString() cannot use ZoneDateTime, it’s possible to have no additional data stored when calling Date.toLocaleString(), but one additional piece of data stored with DateTimeFormat. Note that DateTimeFormat’s entire purpose is a more performant version of toLocaleString(), at least that’s my understanding, and presumably when userland uses these APIs, they will not be creating many of these objects. Adding a little bit of memory when there are few created in order to get performance over time, this seems like a good choice. Users shouldn’t be creating millions of these anyway, since that would be a very bad performance idea. 
+JGT: Note that Date.toLocaleString() cannot use ZoneDateTime, so it’s possible to have no additional data stored when calling Date.toLocaleString(), but one additional bit of data stored with DateTimeFormat. Note that DateTimeFormat’s entire purpose is a more performant version of toLocaleString(), at least that’s my understanding. So if we're concerned about toLocaleString performance, then it'd be possible to specify and implement this change to have no impact at all on toLocaleString. (Not saying we must do this because it'd be extra work, but it's possible if perf is a problem for toLocaleString after this change.) 
+
+Also, because DateTimeFormat objects are intended to be re-used, users won't be creating many of these objects. Adding a little bit of memory when there are few created in order to get performance over time, this seems like an OK tradeoff. Users shouldn’t be creating millions of these anyway, since that would be a very bad performance idea.
 
 YSZ: This sounds great.