I'll add this as a second option to the strawman.
2013/4/9 Sorin Mocanu <[email protected]> > Thank you Nebojša. > How about if the [timezone] parameter would only be passed at the > construction of the Date object? That would (perhaps) allow a user to > centralize timezone validation as well. > > For example: > var date = Date.withTimeZone("America/Los_Angeles", 2013, 3, 9, 15, 11, 0); > var date = Date.withTimeZone("America/Los_Angeles", 1365545496000); > date.getHours(); // 15 > date.getUTCHours(); // 22 > > My 2c, > Sorin > > Sorin Mocanu, Software Engineer > Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland | > 8002 Zurich | Identifikationsnummer: CH-020.4.028.116-1 > > > On Tue, Apr 9, 2013 at 2:46 PM, Nebojša Ćirić <[email protected]> wrote: > >> Wrote a short strawman - >> http://wiki.ecmascript.org/doku.php?id=globalization:timezoneoffsets >> >> >> 2013/4/9 Nebojša Ćirić <[email protected]> >> >>> Sounds about right. We just need to agree it's worth doing it, and in >>> which version of ES and i18n we wanna do it. If we keep tz parameter >>> optional, we would avoid additional data burden on lite JS implementations. >>> >>> >>> 2013/4/9 Domenic Denicola <[email protected]> >>> >>>> From: Nebojša Ćirić [[email protected]] >>>> >>>> > That's correct. We may need reverse too - for given UTC epoch >>>> milliseconds (or minutes after UTC Date) tell me what the date components >>>> would be in a given timezone. >>>> >>>> Hmm, so: >>>> >>>> ```js >>>> var date = new Date(utcMilliseconds); >>>> >>>> var monthInNewYork = date.getMonth("America/New_York"); >>>> var monthInParis = date.getMonth("Europe/Paris"); >>>> ``` >>>> >>>> ? And I guess then `date.getUTCMonth()` is just an alias for >>>> `date.getMonth("Etc./UTC")`. Seems good!! >>>> >>>> >>> >>> >>> -- >>> Nebojša Ćirić >>> >> >> >> >> -- >> Nebojša Ćirić >> > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
