On Mar 4, 2013, at 22:49 , L. David Baron wrote:
> On Saturday 2013-03-02 10:50 -0800, Norbert Lindenberg wrote:
>> On Mar 2, 2013, at 8:46 , Mark Davis ? wrote:
>>> The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used
>>> to have the former as the canonical name (in Zone),
On Saturday 2013-03-02 10:34 -0800, Norbert Lindenberg wrote:
> I think a better solution would be API that either lets you easily
> generate a series of Date instances representing midnight (of
> every day, of every Monday, of every first day of the month, ...)
> in a specified time zone and calen
On Saturday 2013-03-02 10:50 -0800, Norbert Lindenberg wrote:
> On Mar 2, 2013, at 8:46 , Mark Davis ? wrote:
> > The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used
> > to have the former as the canonical name (in Zone), but then changed it to
> > the latter. Here is the c
> I still think the stability issue should be addressed in the IANA time zone
> database itself, not by adopting a IANA-derived alternate registry. Has that
> been tried?
I agree, we should be chatting with the IANA folks.
-Shawn
___
es-discuss mail
lips, Addison
Subject: Re: Internationalization: Support for IANA time zones
On Mar 2, 2013, at 8:11 , Shawn Steele wrote:
> Re: UTC vs Tz names
>
> Sometimes UTC might be “enough”, or “almost enough”, but there’s a big
> difference between Pacific Time and UTC-8, because sometimes it might be
> >
> > The Date constructor and the functions creating Date instances may accept
> values expressed in the local time zone, but are all specified to calculate a
> time
> value in UTC, which then gets stored in the [[PrimitiveValue]].
>
> To speak to Dean's implications, many of the Date methods
On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg
wrote:
>
> On Mar 2, 2013, at 7:27 , Dean Landolt wrote:
>
>> I agree it doesn't make sense to solve this problem in the context of
>> formatting, but there wouldn't be an issue if we had a way to set the zone
>> of a Date. In another thread it
On Mar 2, 2013, at 8:11 , Shawn Steele wrote:
> Re: UTC vs Tz names
>
> Sometimes UTC might be “enough”, or “almost enough”, but there’s a big
> difference between Pacific Time and UTC-8, because sometimes it might be
> UTC-7. So just using UTC doesn’t really help formatting (people want
>
On Mar 2, 2013, at 8:46 , Mark Davis ☕ wrote:
> The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used to
> have the former as the canonical name (in Zone), but then changed it to the
> latter. Here is the current TZDB data:
>
> zone.tab
>
> IN+2232+08822 Asia/Kolk
On Mar 2, 2013, at 7:27 , Dean Landolt wrote:
> I agree it doesn't make sense to solve this problem in the context of
> formatting, but there wouldn't be an issue if we had a way to set the zone of
> a Date. In another thread it was claimed that "A Date is intended to
> represent a specific in
On Sat, Mar 2, 2013 at 5:11 PM, Shawn Steele wrote:
> I’m uncomfortable using the CLDR names, although perhaps they could be
> aliases, because other standards use the tzdb names and we have to be able
> to look up the tzdb names. It might be nice to get more stability for the
> tzdb names, like
Re: CLDR names being “better” than tzdb names.
I’m uncomfortable using the CLDR names, although perhaps they could be aliases,
because other standards use the tzdb names and we have to be able to look up
the tzdb names. It might be nice to get more stability for the tzdb names,
like aliases or
On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ wrote:
> > It seems we have agreement that the canonicalized IANA names are not
> good for formatted strings. I like the CLDR solution, but see it as
> implementation dependent. *Maybe there's just no value in trying to
> define something in the standa
> It seems we have agreement that the canonicalized IANA names are not good
for formatted strings. I like the CLDR solution, but see it as
implementation dependent. *Maybe there's just no value in trying to define
something in the standard since any implementer can claim that "Center,
North Dakota"
T
here are two different issues:
Zone - what we do in CLDR solves the issue. All implementations should, and
as far as I know, do, accept all of the valid TZIDs. Because we use
existing valid TZIDs as the canonical form, even though they are not the
same as in the Zone file, it all works. And we
And the time zone names in formatted output when no localized time zone name is
available:
On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:
> 5) The set of combinations of time zone name and language tag for which
> localized time zone names are available is implementation dependent. Where
ailto:shawn.ste...@microsoft.com>;
es-discuss<mailto:es-discuss@mozilla.org>
Subject: Re: Internationalization: Support for IANA time zones
The identifier issues first:
On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:
> > These names are canonicalized to the corresponding Zone name in the casing
The identifier issues first:
On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:
> > These names are canonicalized to the corresponding Zone name in the casing
> > used
>
> Because the Zone names are unstable, in CLDR we adopted the same convention
> as in BCP47. That is, our canonical form never ch
be happier with it than "America/Los_Angeles".
Addison
> -Original Message-
> From: Norbert Lindenberg [mailto:ecmascr...@lindenbergsoftware.com]
> Sent: Thursday, February 28, 2013 3:36 PM
> To: es-discuss
> Subject: Internationalization: Support for
eting gets moved to a following week, that offset might
> change or be wrong)
>
> -Shawn
>
> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
> On Behalf Of Norbert Lindenberg
> Sent: Thursday, February 28, 2013 3:36 P
ilto:
>> es-discuss-boun...@mozilla.org] On Behalf Of Norbert Lindenberg
>> Sent: Thursday, February 28, 2013 3:36 PM
>> To: es-discuss
>> Subject: Internationalization: Support for IANA time zones
>>
>> I'm updating the ECMAScript Internationalization A
.@mozilla.org [mailto:
> es-discuss-boun...@mozilla.org] On Behalf Of Norbert Lindenberg
> Sent: Thursday, February 28, 2013 3:36 PM
> To: es-discuss
> Subject: Internationalization: Support for IANA time zones
>
> I'm updating the ECMAScript Internationalization API spec to support t
-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Norbert Lindenberg
Sent: Thursday, February 28, 2013 3:36 PM
To: es-discuss
Subject: Internationalization: Support for IANA time zones
I'm updating the ECMAScript Internationalization API spec to support th
I'm updating the ECMAScript Internationalization API spec to support the names
of the IANA Time Zone Database [1] in DateTimeFormat. I'd like to highlight a
few key points of my draft to see whether there are comments:
1) The supported names are the Link and Zone names of the IANA Time Zone
Dat
24 matches
Mail list logo
