PrepareCalendarFields: Replace TO-PRIMITIVE-AND-REQUIRE-STRING conversion #2962
Comments
|
I'd prefer not to add more special treatments in PrepareCalendarFields, but we can put it on the agenda for the next Temporal champions call. |
|
TO-PRIMITIVE-AND-REQUIRE-STRING is used for exactly two fields: Early conversion also ensures bad inputs are caught early and more consistent. (More consistent because |
Correct—«In a calendar with a leap month at the start of some years, the month code of that month would be "M00L"».
That's a good point... we probably should specify that it generalizes the pattern of ISOResolveMonth (first checking to see if unset field(s) warrant a TypeError, then checking values to maybe throw a RangeError). |
Do you happen to know a calendar where a leap month can occur at the start of the year? It looks like the Hindu calendar can have leap months at the start of the year based on this (for the amanta system). But it's not clear (to me) that the current month code scheme actually works for the Hindu calendar, cf. tc39/proposal-intl-era-monthcode#18. Are there any other calendar systems with leap months at the start of the year? |
|
None that I know of (and particularly not in the Chinese calendar AFAIK), but the Temporal champions felt it wise to avoid a syntactic restriction because it is logically possible, and attested in at least some Hindu calendars. |
|
Meeting, 2024-10-03: We're OK to do this as long as it falls into the "Remove calendars and time zones" bucket. If anyone disagrees with that, please holler. |
Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the calendar validate whether the month code actually exists in the year. See tc39/proposal-temporal#2962
…lity Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the time zone validate whether the UTC offset is correct for that exact time in the time zone. See tc39/proposal-temporal#2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the calendar validate whether the month code actually exists in the year. See tc39/proposal-temporal#2962
…lity Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the time zone validate whether the UTC offset is correct for that exact time in the time zone. See tc39/proposal-temporal#2962
Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the calendar validate whether the month code actually exists in the year. See tc39/proposal-temporal#2962
…lity Syntax is validated first. Only after the property bag is fully converted into a Calendar Fields Record does the time zone validate whether the UTC offset is correct for that exact time in the time zone. See tc39/proposal-temporal#2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
Just like
"timeZone"is now eagerly validated using TO-TEMPORAL-TIME-ZONE-IDENTIFIER, also replace the TO-PRIMITIVE-AND-REQUIRE-STRING conversion with stricter checks:"offset"must be parseable as an offset string"monthCode"must match the formatMnn, optionally followed byL, where nn is a non-negative integer, i.e. 0 <= nn <= 99. ("M00L"is apparently valid per https://tc39.es/proposal-temporal/#table-temporal-calendar-date-record-fields?)This is a normative change but should fall into the "Remove calendars and time zone" bucket, which enabled further simplifications to
PrepareCalendarFields.The text was updated successfully, but these errors were encountered: