This is required for Temporal.Duration.prototype.round(). Subsequently,
this now returns ThrowCompletionOr<Optional<String>>, which brings the
signature in line with that of to_smallest_temporal_unit().
Much nicer! :^)
The first step of to_temporal_calendar_with_iso_default() is checking
whether the given value is undefined, so we should actually pass that
instead of unconditionally dereferencing the Optional<String>.
It's not the `to_uint<u8>()` call that would fail, if we have a value
for these productions they will always be valid numbers. We do need to
provide a fallback for when that's not the case and any of them is
undefined, i.e. an empty Optional.
This is the start of a parser for the ISO 8601 grammar used in the
Temporal spec:
https://tc39.es/proposal-temporal/#sec-temporal-iso8601grammar
We will, on purpose, not use a generic ISO 8601 parser from AK or
similar for two reasons:
- Many AOs make specific assumptions about which productions exist and
access them directly, even when they're part of a larger production.
- The spec says "The grammar deviates from the standard given in ISO
8601 in the following ways:" and then lists 17 of such deviations.
Making that work with a general purpose parser is not worth it.
The public API is not being used anywhere yet, but will be in the next
couple of commits. Likewise, the Production enum will be populated with
all the productions accessed directly (e.g. TemporalDateString).
Many thanks to Ali for showing me how to improve my initial approach
full of macros with a nice RAII helper - it's much nicer :^)
Co-Authored-By: Ali Mohammad Pur <mpfard@serenityos.org>
This would return incorrect results for negative inputs. It still does
to some extent, remainder() in step 2 might need to be replaced with
modulo (I opened an issue in tc39/proposal-temporal about that).
481f7d6afa tried to use `modulo()` here, but missed that the
code used `<=` instead of `<`.
Keep using `modulo()` and add an explicit conditional, which is
arguably clearer.
When the resulting week is in the previous year, we need to check if the
previous year is a leap year and can potentially have 53 weeks, instead
of the given year.
Also added a comment to briefly explain what's going on, as it took me a
while to figure out.
...and change the parameter types from i64 to double, as predicted by
a FIXME. The issue here is that integer division with a negative
dividend doesn't yield the same result as floating point division
wrapped in floor().
Additionally, the `days` variable needs to be signed.
This relies on floating point division, which is not possible with
LibCrypto bigints at the moment. So, instead of completely ignoring the
remainder we now first do a bigint division, then convert the remainder
to a double, and do another native floating point division to get the
final result.
It would crash because of VERIFY(largest_unit == "nanosecond"sv) in the
final else branch when passing "week", because it's not handled in any
of the previous branches.
I changed this in 6ef1a27 to "match the spec", but the spec calls it
`match exactly` and `match minutes` - so what we had before was correct
and the change made no sense whatsoever.
Always throws at the moment, because parse_temporal_month_day_string()
is basically a stub, and parse_iso_date_time() isn't functional either.
The spec issue has been resolved though, so I figured we might as well
get one small step further :^)
