Temporal edits #37905
Temporal edits #37905
Conversation
If a Temporal object would represent a date outside of the supported range, this always throws a RangeError, regardless of the value of the overflow option.
github-actions
bot
added
Content:JS
|
Thanks! Is this ready to review as-is, or do you plan to add more stuff to it? |
|
I figured I'd keep this easy to review and open a separate PR when I have another batch of edits, so this is ready to review. (If you'd prefer that I just make one PR instead, let me know and I'll do that.) |
github-actions
bot
added
size/m
|
Weirdly, I can't push to your branch that I checked out with |
|
Oh, thanks for the heads up. That must be a leftover from when I was reviewing Eric's work on this originally! I'll delete my fork and recreate it from the main MDN repo. (But I don't know if that will mess up this PR, so to be safe I'll only do that after this PR gets merged.) In the meantime, let me know if you'd like me to push anything to this branch. |
|
I'm working on extracting all information about valid dates to a shared linkable section, and afterwards I'll merge it. The PR will be closed if the fork gets deleted so yes you should wait until it gets merged. |
|
@ptomato While researching the valid range of Temporal.PlainDate.from("+275760-09-13"); // works
Temporal.PlainDate.from("+275760-09-13").withCalendar("chinese"); // works
Temporal.PlainDate.from("+275760-09-13").withCalendar("chinese").year; // RangeError in both FF and the js-temporal polyfill
Temporal.PlainDate.from("+275760-09-13").withCalendar("chinese").toPlainYearMonth(); // RangeErrorDo non-ISO calendars have smaller ranges of valid values compared to ISO 8601? |
|
@Josh-Cena Good find! I looked into it and I believe this behaviour is not allowed by the spec. Any valid PlainDate object should be guaranteed to be valid in all calendars, and therefore have a valid I've looked at why this happens in the js-temporal polyfill and it's because we don't have a proper calendar implementation, we just fake it using iterative guesses from Intl.DateTimeFormat, and there's a point where we try to query the 1st day of the following year which of course fails in this case. So that's a bug. However, that doesn't explain why this fails on Firefox, maybe a bug in ICU4X? |
|
I've updated this PR with my understanding of valid date ranges. Could you look if it makes sense? (Modulo my question above, which may or may not be worth including in the docs). |
files/en-us/web/javascript/reference/global_objects/temporal/index.md
Outdated
Show resolved
Hide resolved
|
So how does this look? |
|
@Josh-Cena Looks great, ship it! 😄 |
Description
A couple of minor edits to the Temporal docs: a few mislabeled or missing links, a clarification about ±HH:mm:ss.sssssssss offset parts of RFC 9557 strings, and another clarification about the representable range covered by Temporal objects.
Motivation
I was asked to pitch in to help review the original Temporal docs PR, but didn't have time. So I'm going over it now and fixing anything that comes to mind. This is the result of one session of doing that.
Additional details
Related issues and pull requests
Relates to #37344