Just like the previous Temporal.{Instant,TimeZone} commits, this patch
adds the Calendar object itself, its constructor and prototype
(currently empty), and two required abstract operations.
This is Abstract Operation is required for the majority of
InstantConstructor's and InstantPrototype's methods.
The implementation is not entirely complete, (specifically 2 of the
underlying required abstract operations, ParseTemporalTimeZoneString
and ParseISODateTime are missing the required lexing, and as such are
TODO()-ed) but the majority of it is done.
This is an AK::GenericLexer that exposes helper methods for parsing
date and time related literals (years, months, days, hours, minutes,
seconds, fractional seconds & more)
...for the non-success state. This fixes a crash when parsing dates with
the year -1, as we would assert successful parsing ("year != -1").
Mixing Optional and -1 seems worse and more complicated than just using
Optional for all the values, so I did that instead.
It is defined as follows:
21.4.3.1 Date.now ( )
https://tc39.es/ecma262/#sec-date.now
The now function returns the time value designating the UTC date and
time of the occurrence of the call to now.
"Time value" is defined as:
21.4.1.1 Time Values and Time Range
https://tc39.es/ecma262/#sec-time-values-and-time-range
An ECMAScript time value is a Number, either a finite integral
Number representing an instant in time to millisecond precision or
NaN representing no specific instant.
By flooring the value we match the behavior in the Temporal proposal's
Temporal.ZonedDateTime.prototype.epochMilliseconds getter:
4. Let ms be RoundTowardsZero(ℝ(ns) / 10^6).
With that being defined as:
13.30 RoundTowardsZero ( x )
https://tc39.es/proposal-temporal/#sec-temporal-roundtowardszero
1. Return the mathematical value that is the same sign as x and
whose magnitude is floor(abs(x)).
This is makes the last of the currently 15 Temporal tests in test262
work, which compares Temporal.now.instant() with Date.now() :^)
All regex flags supported by LibJS currently correspond to a LibRegex
option, but this is not the case for the RegExp.prototype.hasIndices
proposal, which is handled entirely in RegExpBuiltinExec. Remove the
flag mapping to prepare for this. This incurs a bit of an optimization
loss in the flag getters, as we now do a substring search, but we can
revisit the getter implementation if it becomes an issue.
