Time zone offsets for any time zone, possible change to Date functionality (i18n)

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Sun Apr 14 19:36:59 PDT 2013

On Apr 9, 2013, at 11:30 , Nebojša Ćirić wrote:

> We need to support conversion between:
> {Y, M, D, H, M, S, AnyTimeZone*} <=> {UTC Epoch millis}
> *AnyTimeZone - doesn't have to be system one, supports IANA tz format.

I proposed one direction of this mapping a while ago as "public API for ToLocalTime":

Note that the calendar is also required input along with the time zone, and that for a mapping from field-based time to incremental time you also need the era and whether the time is in DST (for the one hour per year that occurs twice when clocks fall back from daylight saving time to standard time). Throwing in the weekday, which is optional but often desired output, the complete mappings are:

{calendar, time zone, time value} => {weekday, era, year, month, day, hour, minute, second, inDST}
{calendar, time zone, era, year, month, day, hour, minute, second, inDST} => time value

> Since we (i18n) already have timezone data for date formatting, we could do what we did for Date.prototype.toLocaleDateString and extend say Date.prototype.getTimezoneOffset method to support timezone parameter.

I seem to remember that TC 39 had reservations against adding arguments to existing methods - maybe Mark Miller can recall the reasons? For localeCompare and toLocaleString we got away with it because they've been documented all along as likely adding an additional argument in the future.


More information about the es-discuss mailing list