LocalTimeZoneAdjustment/LocalTZA follow-ups necessary

[anba]

In addition to the fixes in #1053:

• Some sentences should be simplified/split-up so they're easier to understand. For example instead of

  "LocalTZA( t, isUTC ) is an implementation-defined algorithm that must return a number representing milliseconds suitable for adding to a Time Value."

  we could just as well just write:

  "LocalTZA is an implementation-defined algorithm that returns the local time zone offset in milliseconds."

• <dfn> seems to be used incorrectly a number of times (i.e. it's not used to define a term, but merely to change the formatting).

• LocalTZA's t parameter is described as a time value. This is incorrect, t can be a number value outside of the allowed range for time values.

• The fourth paragraph seems to imply that a daylight saving time offset is always positive. This is no longer true starting with tzdata2018a.

[littledan]

cc @jungshik

[apaprocki]

@anba I'm curious about your point about LocalTZA accepting Number and not the more restrictive time value. Why do you feel it should accept values outside of the maximum time value range?

[anba]

@apaprocki Because the input can be a local time value which includes the time zone offset, which means it can overflow the maximum allowed time value.

[littledan]

@anba Do you believe the specification currently requires such calculations to be done exactly due to the use of mathematical values in all calculations?

[anba]

@littledan The difference between mathematical values and IEEE-754 numbers resp. it's safe-integer subset is, for once, not relevant. 😄

I think the test case for that issue was something like this.

// Assume the local time offset is positive, let's say TZ=Europe/Berlin.
var d = new Date(8640000000000000); // d.[[DateValue]] = 8,640,000,000,000,000
d.setMilliseconds(0);

20.3.4.23 Date.prototype.setMilliseconds ( ms )

    1. Let t be LocalTime(? thisTimeValue(this value)).
    2. Let ms be ? ToNumber(ms).
    3. Let time be MakeTime(HourFromTime(t), MinFromTime(t), SecFromTime(t), ms).
    4. Let u be TimeClip(UTC(MakeDate(Day(t), time))).
    5. Set the [[DateValue]] internal slot of this Date object to u.
    6. Return u. 

• t in step 1 is then 8640000007200000 (8640000000000000 + 2hr TZA for Europe/Berlin).
• ms in step 2 is 0.
• time in step 3 is 7200000.
• Step 4 then invokes UTC(8640000007200000).

20.3.1.9 UTC ( t )

    1. Return t - LocalTZA(t, false). 

• Calls LocalTZA(8640000007200000, false).
• But t is not a time value, because it's not in (-8640000000000000, 8640000000000000).

Similar, when new Date(NaN).setMilliseconds(0) is called, it invokes LocalTime and LocalTZA with t = NaN.

[apaprocki]

@anba I will incorporate this into my editorial cleanup of LocalTZA.

[apaprocki]

@anba Let me know what you think of the text in #1160. Thanks!

[anba]

The text in #1160 looks good to me! 👍

[jungshik]

The fourth paragraph seems to imply that a daylight saving time offset is always positive. This is no longer true starting with tzdata2018a.

It's dropped but back in tzdata 2018e.

@anba, is your concern about the following ?

at a positive time zone transition (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change)

at a negative time zone transition (e.g. when the daylight saving time ends or the time zone adjustment is decreased due to a time zone rule change)

[apaprocki]

@jungshik I added an explicit statement covering this in my PR:

https://github.com/tc39/ecma262/pull/1160/files#diff-3540caefa502006d8a33cb1385720803R27507

[anba]

@jungshik
Yes, that looks like the sentence my nit-picking was about.