-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NudgeToCalendarUnit: CreateTemporalDate is fallible #2881
Comments
I also don't (yet?) quite understand why the |
@anba That may actually be a mistake on my part. At first glance, it looks like we'd need to call CalendarDateAdd for isoResult1 and then BalanceISODate to just add duration.[[Days]] to isoResult1 to obtain isoResult2. Thanks for catching it; I guess we should treat it as your post-merge code review. As for the original issue, I assumed the CreateTemporalDate calls would not be fallible because isoResult2 would be the equivalent plain date for destEpochNs, which would be within the limits. (But if an arbitrary date could be returned from CalendarDateAdd, that no longer holds.) |
If |
But if you had a duration with calendar units that large, wouldn't it throw already before it got to this point? I should try stepping through this, to make sure... |
DifferenceDate in DifferenceTemporalPlainDate calls user-code for user-defined calendars, so the duration can have arbitrary large values, DifferenceTemporalPlainDate then calls RoundRelativeDuration, which in turn calls NudgeToCalendarUnit. The duration values are unchanged along this call chain, so large values should be possible. (I haven't yet implemented this part in SpiderMonkey, so I'm not 100% sure, but this looks plausible when just reading the spec text.) |
Steps 3.a-d:
The
CreateTemporalDate
calls are fallible.The text was updated successfully, but these errors were encountered: