Spelling (#2610)

* whitespace

Signed-off-by: Josh Soref <[email protected]>

* spelling: anymore

Signed-off-by: Josh Soref <[email protected]>

* spelling: context

Signed-off-by: Josh Soref <[email protected]>

* spelling: discussion

Signed-off-by: Josh Soref <[email protected]>

* spelling: each

Signed-off-by: Josh Soref <[email protected]>

* spelling: from

Signed-off-by: Josh Soref <[email protected]>

* spelling: happens

Signed-off-by: Josh Soref <[email protected]>

* spelling: instead

Signed-off-by: Josh Soref <[email protected]>

* spelling: javascript

Signed-off-by: Josh Soref <[email protected]>

* spelling: kislev

Signed-off-by: Josh Soref <[email protected]>

* spelling: linguistics

Signed-off-by: Josh Soref <[email protected]>

* spelling: localized

Signed-off-by: Josh Soref <[email protected]>

* spelling: milliseconds

Signed-off-by: Josh Soref <[email protected]>

* spelling: nanoseconds

Signed-off-by: Josh Soref <[email protected]>

* spelling: nitty-gritties

Signed-off-by: Josh Soref <[email protected]>

* spelling: nonexistent

Signed-off-by: Josh Soref <[email protected]>

* spelling: polyfillability

Signed-off-by: Josh Soref <[email protected]>

* spelling: precedent

Signed-off-by: Josh Soref <[email protected]>

* spelling: prototype

Signed-off-by: Josh Soref <[email protected]>

* spelling: question

Signed-off-by: Josh Soref <[email protected]>

* spelling: responses

Signed-off-by: Josh Soref <[email protected]>

* spelling: should

Signed-off-by: Josh Soref <[email protected]>

* spelling: substrings

Signed-off-by: Josh Soref <[email protected]>

* spelling: then

Signed-off-by: Josh Soref <[email protected]>

* spelling: which

Signed-off-by: Josh Soref <[email protected]>

* spelling: with

Signed-off-by: Josh Soref <[email protected]>

* spelling: would

Signed-off-by: Josh Soref <[email protected]>

---------

Signed-off-by: Josh Soref <[email protected]>

Author: jsoref

docs/calendar.md

@@ -83,7 +83,7 @@ Here are best practices for writing code that will work regardless of the calend
 - When using the `Temporal.PlainMonthDay` type (e.g. for birthdays or holidays), use its `monthCode` property only.
   The `month` property is not present on this type because some calendars' month indexes vary from year to year.
 - When calling `Temporal.PlainMonthDay.prototype.toPlainDate(year)`, be prepared for the resulting date to have a different day of the month and/or a different month, because leap days and leap months are not present in every year.
-- Use `toLocaleString` to fetch month names instead instead of caching an array of names.
+- Use `toLocaleString` to fetch month names instead of caching an array of names.
   Example: `date.toLocaleString('en-US', { calendar: date.calendar, month: 'long' })`.
   If you absolutely must cache month names, a string key like `${date.calendar.id}|{date.monthCode}|{date.inLeapYear}` will work for all built-in calendars.
 - Don't assume that `era` or `eraYear` properties are always present.

docs/duration.md

@@ -449,7 +449,7 @@ The `roundingMode` option controls how the rounding is performed.
 - `ceil`: Always round towards positive infinity.
   For negative durations this option will decrease the absolute value of the duration which may be unexpected.
   To round away from zero, use `expand`.
-- `expand`:  Always round away from from zero like `ceil` for positive durations and like `floor` for negative durations.
+- `expand`:  Always round away from zero like `ceil` for positive durations and like `floor` for negative durations.
 - `trunc`: Always round towards zero, chopping off the part after the decimal point.
 - `floor`: Always round down, towards negative infinity.
   This mode acts the same as `trunc` for positive durations but for negative durations it will increase the absolute value of the result which may be unexpected.

docs/parse-draft.md

@@ -1,6 +1,6 @@
 This is a draft design document for a `Temporal.parse` API, which is not currently planned to be implemented for several reasons:
 - `Temporal`'s approach to most operations—including parsing—is to encourage strong typing, e.g. `Temporal.Instant.from` vs. `Temporal.PlainDateTime.from`. A type-spanning "parse anything" API goes against that strongly-typed model.
-- The main use case beyond type-specific parsing that was identified for a `parse` API was handling "partially correct" ISO strings, e.g. where only one unit was out of range. Most of these use cases were addressed via the `overflow` option in the `from` method of all types which which either clamps out-of-range values (`'constrain'`) to the nearest in-range value or throws (`'reject'`) in that case.
+- The main use case beyond type-specific parsing that was identified for a `parse` API was handling "partially correct" ISO strings, e.g. where only one unit was out of range. Most of these use cases were addressed via the `overflow` option in the `from` method of all types which either clamps out-of-range values (`'constrain'`) to the nearest in-range value or throws (`'reject'`) in that case.
 - The final remaining case for a `parse` API was resolving the case where a time zone and a time zone offset can be in conflict, as would happen for future `Temporal.ZonedDateTime` values stored before a country permanently abolishes DST. This use case is now handled via the `offset` option of `Temporal.ZonedDateTime.from`.
 
 # parse

docs/plaindate.md

@@ -175,7 +175,7 @@ The above read-only properties allow accessing each component of a date individu
   `month` values start at 1, which is different from legacy `Date` where months are represented by zero-based indices (0 to 11).
 - `monthCode` is a calendar-specific string that identifies the month in a year-independent way.
   For common (non-leap) months, `monthCode` should be `` `M${month}` ``, where `month` is zero padded up to two digits.
-  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with with an "L" suffix appended.
+  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with an "L" suffix appended.
   Examples: `'M02'` => February; `'M08L'` => repeated 8th month in the Chinese calendar; `'M05L'` => Adar I in the Hebrew calendar.
   - `day` is a positive integer representing the day of the month.
 
@@ -746,7 +746,7 @@ When interoperating with existing code or services, this matches the behavior of
 This mode also matches the behavior of cross-platform standards like [RFC 5545 (iCalendar)](https://tools.ietf.org/html/rfc5545).
 
 During "skipped" clock time like the hour after DST starts in the Spring, this method interprets invalid times using the pre-transition time zone offset.
-This behavior avoids exceptions when converting non-existent date/time values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainTime` value in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
+This behavior avoids exceptions when converting nonexistent date/time values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainTime` value in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
 
 For usage examples and a more complete explanation of how this disambiguation works, see [Resolving ambiguity](./ambiguity.md).
 

docs/plaindatetime.md

@@ -242,7 +242,7 @@ Date unit details:
   `month` values start at 1, which is different from legacy `Date` where months are represented by zero-based indices (0 to 11).
 - `monthCode` is a calendar-specific string that identifies the month in a year-independent way.
   For common (non-leap) months, `monthCode` should be `` `M${month}` ``, where `month` is zero padded up to two digits.
-  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with with an "L" suffix appended.
+  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with an "L" suffix appended.
   Examples: `'M02'` => February; `'M08L'` => repeated 8th month in the Chinese calendar; `'M05L'` => Adar I in the Hebrew calendar.
 - `day` is a positive integer representing the day of the month.
 
@@ -1018,7 +1018,7 @@ When interoperating with existing code or services, `'compatible'` mode matches
 This mode also matches the behavior of cross-platform standards like [RFC 5545 (iCalendar)](https://tools.ietf.org/html/rfc5545).
 
 During "skipped" clock time like the hour after DST starts in the Spring, this method interprets invalid times using the pre-transition time zone offset if `'compatible'` or `'later'` is used or the post-transition time zone offset if `'earlier'` is used.
-This behavior avoids exceptions when converting non-existent `Temporal.PlainDateTime` values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainDateTime` in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
+This behavior avoids exceptions when converting nonexistent `Temporal.PlainDateTime` values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainDateTime` in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
 
 For usage examples and a more complete explanation of how this disambiguation works and why it is necessary, see [Resolving ambiguity](./ambiguity.md).
 

docs/plainmonthday.md

@@ -143,7 +143,7 @@ The above read-only properties allow accessing each component of the date indivi
 
 - `monthCode` is a calendar-specific string that identifies the month in a year-independent way.
   For common (non-leap) months, `monthCode` should be ` ` `M${month}` ` `, where `month` is zero padded up to two digits.
-  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with with an "L" suffix appended.
+  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with an "L" suffix appended.
   Examples: `'M02'` => February; `'M08L'` => repeated 8th month in the Chinese calendar; `'M05L'` => Adar I in the Hebrew calendar.
 - `day` is a positive integer representing the day of the month.
 

docs/plaintime.md

@@ -595,7 +595,7 @@ When interoperating with existing code or services, this matches the behavior of
 This mode also matches the behavior of cross-platform standards like [RFC 5545 (iCalendar)](https://tools.ietf.org/html/rfc5545).
 
 During "skipped" clock time like the hour after DST starts in the Spring, this method interprets invalid times using the pre-transition time zone offset.
-This behavior avoids exceptions when converting non-existent date/time values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainTime` value in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
+This behavior avoids exceptions when converting nonexistent date/time values to `Temporal.ZonedDateTime`, but it also means that values during these periods will result in a different `Temporal.PlainTime` value in "round-trip" conversions to `Temporal.ZonedDateTime` and back again.
 
 For usage examples and a more complete explanation of how this disambiguation works, see [Resolving ambiguity](./ambiguity.md).
 

docs/plainyearmonth.md

@@ -169,7 +169,7 @@ The above read-only properties allow accessing the year or month individually.
   `month` values start at 1, which is different from legacy `Date` where months are represented by zero-based indices (0 to 11).
 - `monthCode` is a calendar-specific string that identifies the month in a year-independent way.
   For common (non-leap) months, `monthCode` should be `` `M${month}` ``, where `month` is zero padded up to two digits.
-  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with with an "L" suffix appended.
+  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with an "L" suffix appended.
   Examples: `'M02'` => February; `'M08L'` => repeated 8th month in the Chinese calendar; `'M05L'` => Adar I in the Hebrew calendar.
 
 Either `month` or `monthCode` can be used in `from` or `with` to refer to the month.

docs/timezone.md

@@ -263,7 +263,7 @@ When interoperating with existing code or services, `'compatible'` mode matches
 This mode also matches the behavior of cross-platform standards like [RFC 5545 (iCalendar)](https://tools.ietf.org/html/rfc5545).
 
 During "skipped" clock time like, e.g., the hour after DST starts in the spring, this method interprets invalid times using the pre-transition time zone offset if `'compatible'` or `'later'` is used, or the post-transition time zone offset if `'earlier'` is used.
-This behavior avoids exceptions when converting non-existent `Temporal.PlainDateTime` values to `Temporal.Instant`, but it also means that values during these periods will result in a different `Temporal.PlainDateTime` in "round-trip" conversions to `Temporal.Instant` and back again.
+This behavior avoids exceptions when converting nonexistent `Temporal.PlainDateTime` values to `Temporal.Instant`, but it also means that values during these periods will result in a different `Temporal.PlainDateTime` in "round-trip" conversions to `Temporal.Instant` and back again.
 
 For usage examples and a more complete explanation of how this disambiguation works and why it is necessary, see [Resolving ambiguity](./ambiguity.md).
 

docs/zoneddatetime.md

@@ -172,7 +172,7 @@ When interoperating with existing code or services, `'compatible'` mode matches
 This mode also matches the behavior of cross-platform standards like [RFC 5545 (iCalendar)](https://tools.ietf.org/html/rfc5545).
 
 During "skipped" clock time like the hour after DST starts, this method interprets invalid times using the pre-transition time zone offset if `'compatible'` or `'later'` is used or the post-transition time zone offset if `'earlier'` is used.
-This behavior avoids exceptions when converting non-existent local time values to `Temporal.ZonedDateTime`.
+This behavior avoids exceptions when converting nonexistent local time values to `Temporal.ZonedDateTime`.
 
 For usage examples and a more complete explanation of how this disambiguation works and why it is necessary, see [Resolving Ambiguity](./ambiguity.md).
 
@@ -308,7 +308,7 @@ Date unit details:
   `month` values start at 1, which is different from legacy `Date` where months are represented by zero-based indices (0 to 11).
 - `monthCode` is a calendar-specific string that identifies the month in a year-independent way.
   For common (non-leap) months, `monthCode` should be `` `M${month}` ``, where `month` is zero padded up to two digits.
-  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with with an "L" suffix appended.
+  For uncommon (leap) months in lunisolar calendars like Hebrew or Chinese, the month code is the previous month's code with an "L" suffix appended.
   Examples: `'M02'` => February; `'M08L'` => repeated 8th month in the Chinese calendar; `'M05L'` => Adar I in the Hebrew calendar.
 - `day` is a positive integer representing the day of the month.
 

meetings/agenda-minutes-2018-06-18.md

@@ -24,8 +24,8 @@ Agenda and notes:
     * PD: There are a couple translation methods that make it integrate with Date more easily. It’s based on one BigInt, as opposed to two Numbers.
     * MPT: I’m not concerned about the Date conversions; I’m more concerned about any time we’re accessing data from the global state
     * DE: Let’s not focus on ocap concerns; SES can deal with this, as it’s analogous to the Date constructor, and extremely useful.
-    * MPT: Everyone fine with nanonseconds since epoch?
-    * AP: If you have the storage for nanonseconds since epoch, seems fine.
+    * MPT: Everyone fine with nanoseconds since epoch?
+    * AP: If you have the storage for nanoseconds since epoch, seems fine.
     * MPT: Any scenarios where we don’t have 64 bits of storage?
     * AP: BigInt is arbitrary, so if BigInt lands in the spec, we can store whatever.
     * MPT: Now, we can have the BigInt constructor.

meetings/agenda-minutes-2019-01-08.md

@@ -26,7 +26,7 @@ Agenda and notes  (please suggest your own additions/refinements):
         * DE: Stage 2! Hooray
         * PD: Actual management buy-in!
     * Explainer/documentation
-        * PD: I can get a start on this, and coordinate with those who want to do the heavy lifting of comparative lingistics
+        * PD: I can get a start on this, and coordinate with those who want to do the heavy lifting of comparative linguistics
         * DE: It's also important to have documentation in MDN.  The MDN folks are really interested in getting documentation for in-progress proposals so they can be a vector to get feedback.  There is a TC39 outreach group and we are working with MDN.  PD, are you interested in writing MDN documentation?
         * MP: I would expect to see API churn… we could try… maybe it would be helpful for us to write MDN documentation as an exercise that could be informative.
         * DE: Yeah, maybe the process of writing up documentation could make us realize that it is weird.
@@ -35,7 +35,7 @@ Agenda and notes  (please suggest your own additions/refinements):
         * MP: This sort of blocks on the modules question
     * Strategy for modules
         * DE: Apple, Google are both pushing for built-in modules outside TC39.  There are GitHub comments I've read.  Apple doesn't really have time to write the spec.  And there are open questions about how polyfills, namespaces, etc., should work with built-in modules.  I expect to see this come up at TC39.  We could be a force on this, or we could go with the flow.
-        * PD: The questoin to me is, if we push for this / advance it as a good use case, hich I think it is, what are the chances of this getting blocked on built-in modules since there is always disagreement when we bring it up?  Because I think it's more important to get Temporal through than to hitch it to built-in modules, even though it is a perfect use case.
+        * PD: The question to me is, if we push for this / advance it as a good use case, which I think it is, what are the chances of this getting blocked on built-in modules since there is always disagreement when we bring it up?  Because I think it's more important to get Temporal through than to hitch it to built-in modules, even though it is a perfect use case.
         * DE: The points of disagreement have been shifting.  No one is really saying "no built-in modules", but people have specific concerns now.  My feeling is that, Temporal is a proposal that polyfills really well.  So one part is getting this shipped in browsers, and another step is getting API adoption.  So, it would be OK if it takes a little longer to get into browsers if it gets high ecosystem adoption first with the polyfill.  So this is an opportunity for us to be a champion of built-in modules.
         * PD: I think it makes sense.  We should re-evaluate it in March and June.
         * MP: Is built-in modules on the agenda for January?
@@ -80,7 +80,7 @@ Agenda and notes  (please suggest your own additions/refinements):
         * RG: I'd like this to be a sequence of proposals.
         * JW: I could believe that proceeding in stages could be useful, if we're defining one bit of syntax, continuing on, we could collect in-field telemetry.
         * RG: It's also possible that we could end up in a good state where the spec says, if the input is not fully specified, then implementations are free to fall back to whatever, but it's recommended to take a certain action. When I talk about multiple proposals, I'm talking about two: the preferred syntax, and then defining it fully. I don't want to do nothing just because we can't do everything.
-        * DE: Maybe we could start towards trying to define things completely, and then 
+        * DE: Maybe we could start towards trying to define things completely, and then
     * Do we want to propose adding new features to Date, or only to Temporal?
         * DE: I thought we were going to focus on adding things to Temporal, and not add things to Date.
         * RG: I agree, this is a good default position. I don't think we need to add timezones into Date.
@@ -97,5 +97,5 @@ Agenda and notes  (please suggest your own additions/refinements):
         * RG: Yeah, that's totally fair.
         * JW: I think the extension idea is sort-of right, but really it's more of a union.
 * Next steps
-    * Should we make this a recurring (e.g., monthly) meeting?	
+    * Should we make this a recurring (e.g., monthly) meeting?
         * Yes, will repeat monthly

meetings/agenda-minutes-2019-11-12.md

@@ -37,7 +37,7 @@ Agenda:
             * PD: You can pass in the TimeZone to an Absolute.toString()
             * US: Do we need to have subtypes to DateTime, like Date or Time?
             * DE: I guess the reason why not is that you might pass just a Date or just a Time?
-            * SC: We could follow the pattern of Intl.Segmenter and return an object that has getters, so it woulld be lazy
+            * SC: We could follow the pattern of Intl.Segmenter and return an object that has getters, so it would be lazy
             * PD to comment with a resolution
         * [https://github.com/tc39/proposal-temporal/issues/198](https://github.com/tc39/proposal-temporal/issues/198)
             * RG: ISO allows alphabetic components in any case; ISO expresses a preference for a , but allows a .