Hi Norbert,
Sorry for not having better explained my suggestion.
`var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11,
0);` would create a Date object with a local time for
America/Los_Angeles, regardless of my computer's timezone. The difference
is that calls to date.getHours
Le 15 avr. 2013 à 09:27, Sorin Mocanu sorinmoc...@google.com a écrit :
Hi Norbert,
Sorry for not having better explained my suggestion.
`var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11, 0);`
would create a Date object with a local time for America/Los_Angeles,
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
I'll add this as a second option to the strawman.
2013/4/9 Sorin Mocanu sorinmoc...@google.com
Thank you Nebojša.
How about if the
Le 15 avr. 2013 à 14:43, Dean Landolt d...@deanlandolt.com a écrit :
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
I'll add this as a second option to the strawman.
2013/4/9
Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date wouldn't
carry its timezone with it. However, in my proposed world it would be
On Mon, Apr 15, 2013 at 10:01 AM, Dean Landolt d...@deanlandolt.com wrote:
Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I'm afraid this would be quite confusing. Many people believe already that
Date instances are in some local time zone, which they aren't, and this
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I'm afraid this would be quite confusing. Many
On Apr 15, 2013, at 9:23 , Dean Landolt wrote:
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Mon, Apr 15, 2013 at 2:13 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 9:23 , Dean Landolt wrote:
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
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
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
I'll add this as a second option to the strawman.
2013/4/9 Sorin Mocanu sorinmoc...@google.com
Thank you Nebojša.
How about if the [timezone] parameter would only be passed at the
construction of the Date object? That would (perhaps)
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.
We currently implement that by using the Javascript Date object's UTC
representation and TimeZone knowledge which can provide the
From: Nebojša Ćirić [c...@google.com]
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.
This sounds amazing. Please do this.
To
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.
2013/4/9 Domenic Denicola dome...@domenicdenicola.com
From: Nebojša Ćirić [c...@google.com]
Since we (i18n) already have
From: Nebojša Ćirić [c...@google.com]
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 =
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 dome...@domenicdenicola.com
From: Nebojša Ćirić
Wrote a short strawman -
http://wiki.ecmascript.org/doku.php?id=globalization:timezoneoffsets
2013/4/9 Nebojša Ćirić c...@google.com
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
I'll add this as a second option to the strawman.
2013/4/9 Sorin Mocanu sorinmoc...@google.com
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.
19 matches
Mail list logo
