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).