The Array exotic [[DefineOwnProperty]] must capture and reject such
writes with RangeError. Handling for this is integrated into Duktape's
"putprop" algorithm and also defineProperty(). Other internals must
either use "putprop" or implement a similar check carefully.
Checks various base values for which the special behavior should or
should not apply. Also tests various target values for which the
behavior should or should not apply.
When a base object has the special [[Get]] behavior described in E5.1
Section 15.3.5.4 or 10.6 for the "caller" property, there is a question
whether a TypeError is thrown when the "caller" property value is a
bound strict function (or only when the value is a non-bound strict
function).
This commit changes the behavior so that a TypeError is also thrown
when the "caller" value is a bound function, by ensuring that strict
bound functions have the "strict" internal flag set.
The algorithm to iterate for a tzoffset when given local time parts can
start alternating between two values on some DST transitions. This diff
adds explicit support to delete such a loop and consistently select the
higher tzoffset in this case. This makes Duktape match Rhino/V8 behavior
for such ambiguous cases.
These cases arise when a local time which can never exist is used. For
instance, when going from non-DST to DST, there is one hour of local time
which is never used by actual timestamps. Specifying such as time for
the Date constructor has no well defined result.
The algorithm is now combined into the timeval-to-parts algorithm because
it's convenient for the call site. The equivalent year algorithm needs
to figure out the days-since-epoch for Jan 1 of the input year, which the
timeval-to-parts algorithm already knows.
It may be that equivalent year mapping is needed elsewhere too, e.g.
Windows time algorithms which may need it outside of timeval-to-parts
conversion (e.g. the current Windows tzoffset algorithm does not use
timeval-to-parts). A separate or shared implementation can then be
written.
There was a bug in the earlier draft of the equivalent year algorithm: the
weekday must be for the start of the input year, not for the day referred
to by the input timestamp.
Use an iterative algorithm to get the proper tzoffset when creating a
Date from local time parts. Not sure if this is the best approach but
currently the only tzoffset primitive available is tzoffset-for-utctime
(more accurately, tzoffset-for-timevalue).