| Age | Commit message (Collapse) | Author |
|---|
|
When converting to UTC, the UTC AO first tries to disambiguate possible
time zone offsets for the given local time. When doing so, the
GetNamedTimeZoneEpochNanoseconds AO must *subtract* the found time zone
offset from the local time to convert to UTC. The same is performed
later in the UTC AO when returning the final UTC time (step 5).
|
|
This is a normative change in the ECMA-262 spec. See:
https://github.com/tc39/ecma262/commit/43fd5f2
For the most part, these AOs are hoisted from Temporal.
Note that despite being a normative change, the expectation is that
this change does not result in any behavior differences.
|
|
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
|
|
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
|
|
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
|
|
There was an awful lot of JS::Value <-> double conversion going on, even
through these AOs only work with number values anyway.
They don't need a global object either as they won't allocate or throw,
that was simply to pass it to infallible calls of ToIntegerOrInfinity.
|
|
We use a double for [[DateValue]] and the spec's own AOs for any
calculations now.
|
|
They can remain in this header, but will be used outside the Date
context in Temporal.
|
|
This is an editorial change in the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/8e572b6
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
|
|
Return whether the time zone is in DST during the provided time from
TimeZone::get_time_zone_offset,
|
|
Includes HourFromTime, MinFromTime, SecFromTime, msFromTime.
|
|
|
|
|
|
When we multiple by 365, ensure the result is a double (not an i32) to
prevent overflow.
|
|
Implementing years_to_days_since_epoch without a loop will be tricky.
The TimeFromYear AO gives a good enough approximation for MakeDay until
we figure that out.
|
|
These are needed outside of the Date object .cpp file, so move them to
the header.
|
|
|
|
First, this adds a constructor to the Date object to be created from a
plain double. This is a first step to removing Core::DateTime as the
basis for the Date object. A subsequent commit will remove the now-
unused data from the object.
Next, this implements the constructor in accordance to the spec. The
constructor when NewTarget is undefined no longer allocates a Date on
the heap. The other constructor properly uses recently created AOs to
handle time zone and ensure the created [[DateValue]] is valid. Other
methods on the constructor (Date.now) have not been touched yet.
Last, the prototype is reimplemented. Again, we use other AOs to handle
time zones and time clipping. Not all prototypes are fixed; most of them
are, but a few (e.g. Date.prototype.getTimezoneOffset) were not fixed,
but left in a mostly unimplemented state for another commit.
In all of the above, spec comments are added. This is a rather large
change; but it's tough to do any of these parts individually without
breaking everything else.
|
|
It is undefined behavior to cast from a double to an integer if the
value does not fit in the limits of the integer.
|
|
In commmit 7d2834344a7635ec45aba28a0351feca8e5f1c17, I think I combined
the definitions of the LocalTZA and UTC AOs in my head, and thought the
offset should be negated within LocalTZA. Instead, the offset should be
left untouched, and the UTC AO is responsible for doing the subtraction.
|
|
|
|
|
|
Intl.DateTimeFormat will invoke this AO with isUTC=true, so this only
implements that branch in LocalTZA.
|
|
We currently use Core::DateTime create, which internally uses mktime().
This has the issues pointed out by the (now removed) FIXME, but also has
an issue on macOS where years before 1900 are not supported.
|
|
It's a bit annoying having to add '.0' to y given that it's an integral
number in most cases.
This turns the single template parameter T into T and U to permit that.
|
|
|
|
|
|
These all would return incorrect results for negative time values.
Also adds a missing floor() in sec_from_time().
|
|
|
|
A year has 365.2425 days, not 365. This lead to off-by-one results for
time values (milliseconds) near the end of a year, which would lead to
calculation issues and crashes in other AOs.
Fixes #10796.
|
|
DateTime::create() and subsequently DateTime::set_time() uses mktime()
internally to ensure out-of-range input values still result in a valid
date (Jan 32 -> Feb 1 etc.).
This however also means that the input is treated as local time, and
then shifted to UTC accordingly for the returned time_t - it is however
already in UTC in this case! The temporary solution is simply to set the
"TZ" environment variable to "UTC" and back after create(). The proper
solution is probably to have better timezone support in Core::DateTime.
This should only affect Lagom, as serenity itself has no timezone
support yet and always assumes UTC.
|
|
Just like in the previous commit, the day value of Core::DateTime is
one-based, not zero based.
Noticed while implementing a new Temporal function, this likely would've
been caught earlier if we'd also use it for the Date API (we don't).
|
|
|
|
As the specification says "but if this is not possible (because some
argument is out of range), return NaN."
|
|
|
|
We don't have these yet as our Date implementation doesn't use the time
value algorithms and AOs from the spec, but Temporal will need these in
various contexts.
|
|
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.
|
|
Resolves various FIXMEs :^)
|
|
We need to support the range of -999 to 999.
|
|
Since theres no way to drop the arguments before the call to the
constructor (or to signal to the constructor that it was not called
directly), we simply reuse the code for the no arguments provided
special case. (And to prevent code duplication, the code was extracted
into the separate static function Date::now(GlobalObject&).
|
|
|
|
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
Setting an invalid value on a Date object now makes it invalid.
Setting it again but with correct values makes it valid again.
|
|
|
|
|
