Calculation of daylight saving time is wrong

[LaszloLango]

After the PST -> PDT change some of the test262 tests are failed. The reason is the wrong daylight saving time. ecma_date_daylight_saving_ta in ecma-builtin-helpers-date.c is get the daylight saving adjustment from the system, but it gets it for the current date and not for the date we must set (e.g.: new Date(1969, 12)).

=== Summary ===
 - Ran 11552 tests
 - Passed 11546 tests (99.9%)
 - Failed 6 tests (0.1%)

Failed tests
  ch15/15.9/15.9.3/S15.9.3.1_A5_T1 in non-strict mode
  ch15/15.9/15.9.3/S15.9.3.1_A5_T2 in non-strict mode
  ch15/15.9/15.9.3/S15.9.3.1_A5_T3 in non-strict mode
  ch15/15.9/15.9.3/S15.9.3.1_A5_T4 in non-strict mode
  ch15/15.9/15.9.3/S15.9.3.1_A5_T5 in non-strict mode
  ch15/15.9/15.9.3/S15.9.3.1_A5_T6 in non-strict mode

[zherczeg]

Can we do this? I mean countries just change their day-light saving system all the time, and figuring out what was in the past seems difficult.

[LaszloLango]

I don't know what we can do with this. It is really a difficult question, so I'm open for any good idea.

[zherczeg]

Hm perhaps only one daylight saving could be enough, the local one. So we don't care about the physical location of the date. Perhaps we could add US daylight saving system for Jerry, and people could add more if they need it.

[akosthekiss]

Note that the standard explicitly deals with this:

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result.

(ES5.1 15.9.1.8)

Thus, Jerry does not have to track the evolution of the daylight saving system. It can (actually, it should) project the system currently in effect back in the past.

[guilt]

I think adding a comprehensive history may cause us to increase the size of the library. The standard makes it simpler to project today's rules into the past.

[crazy2be]

Note that the spec has changed here as of ES6 [1]:

20.3.1.8 Daylight Saving Time Adjustment

An implementation dependent algorithm using best available information on time zones to determine the local daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds. An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment.

NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.

It changed again in ES9, the current draft is now very explicit again (and much more correct than in ES5):

LocalTZA( t, isUTC ) is an implementation-defined algorithm that must return a number representing milliseconds suitable for adding to a Time Value. The local political rules for standard time and daylight saving time in effect at t should be used to determine the result in the way specified in the following three paragraphs.

When isUTC is true, LocalTZA( t, true ) should return the offset of the local time zone from UTC measured in milliseconds at time represented by time value t (UTC). When the result is added to t (UTC), it should yield the local time.

When isUTC is false, LocalTZA( t, false ) should return the offset of the local time zone from UTC measured in milliseconds at local time represented by time value tlocal = t. When the result is subtracted from the local time tlocal, it should yield the corresponding UTC.

When tlocal represents local time repeating multiple times 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) or skipped local time at a positive time zone transitions (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change), tlocal must be interpreted with the time zone adjustment before the transition.

If an implementation does not support a conversion described above or if political rules for time t are not available within the implementation, the result must be 0.

I'm thinking of fixing this by changing jerry_port_get_time_zone into jerry_port_get_local_tza(double t_ms, bool is_utc). The jerry_port implementation can then provide as complete or incomplete of an implementation as desired or appropriate for the hardware platform. The default jerry_port_get_time_zone would then look something like

double jerry_port_get_local_tza (double unix_ms,  /**< ms since unix epoch */
                                 bool is_utc)  /**< Is the time above in utc? */
{
#ifdef __GNUC__
  struct tm tm;
  time_t now = (time_t)(unix_ms / 1000);
  localtime_r(&now, &tm);
  return tm.tm_gmtoff * 60 * 1000;
#endif /* __GNUC__ */

  return 0;
} /* jerry_port_get_local_tza */

Note that this implementation is not quite correct - we always assume the given timestamp is in UTC, even if is_utc is false. The consequence here is that for times around the dst transition which are in localtime, we will return an offset that is off by an hour. However, it is an order of magnitude more correct than the current implementation, and the jerry_port interface allows for a completely correct interface to be implemented if a port author desired to implement one. (Even handling Lord Howe Island correctly!)

[1] https://www.ecma-international.org/ecma-262/6.0/#sec-daylight-saving-time-adjustment
[2] https://www.ecma-international.org/ecma-262/9.0/#sec-local-time-zone-adjustment