Add TZOffset{UTC,Local} in place of LocalTZA/DSTA

[jungshik]

Currently, LocalTimezoneAdjustment is assumed to be constant across time
zone rule changes and does not take any argument. Daylight Savings Time
Adjustment does take an argument t.

DSTA(t) can 'absorb' the standard time zone offset changes (e.g. Europe/Moscow
changed the standard time zone offset multiple times in the last decade.). However,
the spec stipulates that it should only reprsent an additional
adjustment necessary when DST is in effect.

In practice, at least two implementations (Spidermonkey/Firefox and
JSC/Safari) do not follow the spec to the letter to produce results
expected by users across time zone rule changes.

This PR drops LocalTZA and DaylightSavingsTimeAdjustment(t) and
introduce TZOffsetUTC(t) and TZOffsetLocal(t_local). The former takes
't' (UTC) and gives a time zone offset in effect at t for the local
time zone (for US ET, it'd be 4*msPerHour in summer and 5*msPerHour in
winter). The latter takes 't_local' (local time value) and gives a time
zone offset in effect at t_local.

It's also specified that TZOffsetLocal(t_local) will return the offset
after the transition when t_local is wall time repeating multiple
times at a negative transition (e.g. fall backward) or skipped wall time
at a positive time zone transition (e.g. spring forward). This is in
line with the aforementioned two implementations. In the future, it
may as well be considered to introduce options to control this behavior.
[1] [2]

UTC(t_local) and Localtime(t) are reformulated with
TZOffsetLocal(t_local) and TZOffsetUTC(t).

Will fix #725 modulo an option to specify the behavior to handle
skipped or repeated wall time.

[1] ICU Calendar API has skipped wall time option (https://goo.gl/h0bP26) and
repeated wall time option (https://goo.gl/Q1VX3j).

[2] Python proposal to handle skipped/repeated time:
https://www.python.org/dev/peps/pep-0495/

[jungshik]

@bterlson, @ediosyncratic, @littledan

Can you take a look? I ended up making a bit more extensive change than I thought at first.

@bterlson, I hope it's not too late for review at a ecma262 meeting next week.

BTW, I may not have done the right thing when making this PR in terms of what file to touch etc. Somehow, 'npm install', 'npm run build' etc didn't work on my Ubuntu (14.x). So, I just edited spec.html trying to follow the mark-up style as faithfully as I can.

[jungshik]

The update is to make the sign of TZOffSetUTC and TZOffsetLocal to be the same as that of Date.prototype.getTimezoneOffset. It's unfortunate that the sign of getTimezoneOffset is the opposite of what most people consider 'intuitive'.

An alternative would be not to use 'Offset' in the names of two operations I'm introducing and make the sign be in line with a more common usage (negative for timezone West of the primary meridian and positive for timezones East of the primary meridian) . Instead of 'Offset', 'Adjustment' can be used.

Yet another alternative would be to note that the sign of offsets returned by two operations is the opposite of getTimezoneOffset() and keep the name ('offset') in my PR.

[jungshik]

I have another thought. Instead of introducing two new abstract operations in place of LocalTZA and DSTA(t), I can make LocalTZA take two arguments, t and is_local_time. When is_local_time is true, 't' would be interpreted as a 'local time value' in the current time zone, while 't' would be time value in UTC when it's false.

The reason for is_local_time (boolean) is that 't' needs to be interpreted differently depending on whether 't' is UTC or local time in the current time zone.

That way, I don't have to worry about the sign of TZOffSet{UTC,Local} and can also avoid rather clumsy name with UTC or Local at the end.

I'll make a new PR with this update (to avoid clutter with multiple commits). I'll try to get in this afternoon (UTC-0800). Hope it's not too late for TC39 review this week.

[jungshik]

I'm closing this PR in favor of #778.

[ediosyncratic]

I think this is the better starting-point; it won't create backwards-compatibility problems and does let us do the job properly.

[ediosyncratic]

This function needs a second, optional parameter, by which to sanitize spring-forward gaps and disambiguate fall-back duplications. Given that you want the default behaviour to be "use the offset that was in effect before the transition", that optional parameter needs to select between before and after; so I suggest it be called prior and default to true; it says whether to use the offset in effect before a transition, when the specified time falls into one; if given and false, it selects the offset in effect after the transition.

[ediosyncratic]

No need for "multiple times" - given that "repeating" implicitly says that - and explicitly saying "multiple times" rather than "twice" suggests more than twice, which does never happen and we have no sane way to cope with it if it did.

also: s/the daylight savings time/daylight-saving time/g
... and, at the end, s/after/before/, but description of the argument "prior" should cover this.

[ediosyncratic]

Missing subscript local on first t.