Thank you for renaming padLeft/padRight to padStart/padEnd.
On the treatment of code units, I was hoping to find more detail in the meeting
minutes, but haven’t seen those yet. The native encoding of strings in the
language, with the exception of a few parts that we haven’t been able to fix in
The TC39 meeting in September discussed a proposal to add padLeft and padRight
methods to String; the relevant section of the meeting notes [1] is attached
below. A revised proposal is on the agenda for the upcoming November meeting
[2].
Comments on this proposal:
1) The proposal notes that
Intl.DateTimeFormat doesn’t currently let you specify a custom pattern in
ICU/CLDR format. The reason is that the API had to be implemented on top of
different existing internationalization APIs, and the API on Windows didn’t
support CLDR date format patterns.
There is a feature request for
unicode bidirectional stuff.
On Mon, Jul 20, 2015 at 11:25 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
These methods should be called trimStart and trimEnd. Determining which parts
of the string are left and right would require running the Unicode
Bidirectional Algorithm
That’s very sad, because they’re wrong, not “wrong”.
Norbert
On Jul 20, 2015, at 23:29 , Domenic Denicola d...@domenic.me wrote:
They're already shipping with the wrong names in every browser.
From: Norbert Lindenberg ecmascr...@lindenbergsoftware.com
Sent: Jul 20, 2015 23:25
These methods should be called trimStart and trimEnd. Determining which parts
of the string are left and right would require running the Unicode
Bidirectional Algorithm, and that’s probably not intended here.
Norbert
On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.com
A note for those who care about ECMAScript internationalization: Rick Waldron
has taken over as the editor of the ECMAScript Internationalization API
Specification, and has published a new draft of the second edition:
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
The
On Jan 28, 2015, at 8:11 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 28, 2015, at 2:36 AM, Marja Hölttä ma...@chromium.org wrote:
Hello es-discuss,
TL;DR: /foo.bar/u.test(“foo\uD83Dbar”) == ?
The ES6 unicode regexp spec is not very clear regarding what should happen
On Jan 28, 2015, at 8:30 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 28, 2015, at 4:54 AM, Wes Garland w...@page.ca wrote:
Do we extend the regexp syntax to have a symbol which matches an unmatched
surrogate?
we already have it: \u{D83D}
Or to match any unpaired
I think the change proposed by Allen is fine. The main point of the new
definition of IdentityEscape is to reserve \p, \X, and other escape sequences
involving ASCII letters, to which we may want to assign different
interpretations in the future. Allowing \- does not conflict with this.
On Aug 26, 2014, at 10:01 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
So, here is a summary of my proposal:
3) Reserve within /u RegExp patterns, the syntax \p{characters} and
\P{characters}
This was already decided by TC39 at the March 2012 meeting, and if I read the
spec correctly,
On Aug 26, 2014, at 11:15 , Mathias Bynens math...@qiwi.be wrote:
On 26 Aug 2014, at 19:01, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I see one remaining issue:
In ES5 (and ES6): `/a-z/i` does not match U+017F (ſ) or U+212A (K) because
the ES canonicalization algorithm excludes
On Aug 25, 2014, at 1:59 , Mathias Bynens math...@qiwi.be wrote:
Norbert’s original proposal for the `u` flag
(http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/#RegExp)
mentioned the following:
Possibly the definition of the character classes `\d\D\w\W\b\B` is
On Jun 17, 2014, at 17:28 , David Herman dher...@mozilla.com wrote:
This was brought up on specifiction:
http://discourse.specifiction.org/t/navigator-timezone/152
Does anyone know why it was left out of the first version of the Intl API?
Just for lack of time? Is it planned for the
The time zone the user wants to use, and therefore sets in the OS, is not
always tied to the current location. For example, on a flight from San
Francisco to Frankfurt I care about Pacific Time and Central European Time, but
not the other time zones I fly over. There are also locations for
As Luke phrased it two years ago: “The current [ES 5.1] spec text allows
implementations to be as wrong as they'd like about daylight savings
adjustments, but constrains how correct they should try to be. This is
somewhat counterintuitive, and in practice, has not succeeded in producing
[Dropping whatwg@ and public-script-coord@ since this appears to be an
ECMAScript issue.]
On May 19, 2014, at 11:34 , Garrett Smith dhtmlkitc...@gmail.com wrote:
On 1/19/14, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote:
On Jan 19, 2014, at 10:01 , Jasper St. Pierre jstpie
On Mar 6, 2014, at 15:46 , Axel Rauschmayer a...@rauschma.de wrote:
– Regular expressions: https://gist.github.com/slevithan/4222600
– Escaping the variable parts of domain-specific languages
– HTML templates (think Facebook’s React)
– Internationalization
Not internationalization. The
On Jan 19, 2014, at 10:01 , Jasper St. Pierre jstpie...@mecheye.net wrote:
On Sunday, January 19, 2014, Garrett Smith dhtmlkitc...@gmail.com wrote:
What considerations are there for codifying the behavior for
Date.parse? Middle endian date format parsing works:
Date.parse(2/11/2013);
All ECMAScript objects have a toLocaleString method, originally defined in
Object.prototype and overridden in Array, Number, and Date. The parameter list
of this method has changed over time:
- In ES3 and ES5, the methods don't take parameters, but there's a note The
first parameter to this
The internationalization working group is planning to support grapheme clusters
through its text segmentation API - the strawman:
http://wiki.ecmascript.org/doku.php?id=globalization:text_segmentation
Note that Unicode Standard Annex #29 allows for tailored (language sensitive)
grapheme
On Oct 24, 2013, at 7:38 , Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 24, 2013 at 3:31 PM, Mathias Bynens math...@qiwi.be wrote:
Imagine you’re writing a JavaScript library that escapes a given string as
an HTML character reference, or as a CSS identifier, or anything else. In
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote:
UTF-16 is designed so that you can search based on code units
alone, without computing boundaries. RegExp searches fall in this
category.
Not if the RegExp is case insensitive, or uses a character class, or ., or a
On Oct 26, 2013, at 5:39 , Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Norbert Lindenberg wrote:
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com
wrote:
UTF-16 is designed so that you can search based on code units
alone, without computing boundaries. RegExp searches
On Oct 26, 2013, at 6:58 , Jason Orendorff jason.orendo...@gmail.com wrote:
On Fri, Oct 25, 2013 at 11:42 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com
wrote:
UTF-16 is designed so that you can
On Oct 9, 2013, at 0:27 , Mathias Bynens math...@qiwi.be wrote:
- Step 11 would allow all Unicode code points that are matched by the
IdentifierStart production, including supplementary code points, which ES 5
does not permit in identifiers. (Note that Unicode 3.0, the version
referenced
On Sep 5, 2013, at 1:06 , Mathias Bynens math...@qiwi.be wrote:
On 26 Aug 2013, at 04:08, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Aug 24, 2013, at 23:43 , Mathias Bynens math...@qiwi.be wrote:
I would suggest adding something like `String.isIdentifier` which
On Sep 5, 2013, at 14:12 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Sections 17-26 define the ECMAScript standard library. It includes the
definitions of all of the standard objects that are available for use by
ECMAScript programs as the execute.
In previous editions this was
$ 'Hallo Friedrichstraße'.contains('STRASSE', { ignoreCase: true })
true? false?
$ 'hello İzmir'.contains('İZMİR', { ignoreCase: true })
true? false?
In other words, should ignoreCase be based on Unicode upper case conversion,
lower case conversion, or case folding, with or without locale
On Aug 24, 2013, at 23:43 , Mathias Bynens math...@qiwi.be wrote:
I would suggest adding something like `String.isIdentifier` which accepts a
multi-symbol string or an array of code points to the strawman. Seems useful
to be able to do `String.isIdentifier('foobar')`
What would be the use
I had no intentions specific to U+2E2F when I proposed relying on UTR 31 - the
change is simply the effect of the character properties that the Unicode
Technical Committee assigned to this character.
I don't think there's a real problem. U+2E2F was added in Unicode version 5.1.
ECMAScript 5.1
On Aug 24, 2013, at 2:02 , Mathias Bynens math...@qiwi.be wrote:
On 27 Feb 2012, at 22:58, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
var \ud87e\udc00 would probably still be illegal because each \u define
a separate character but: var \u{2f800} =42; schould be find as should the
On Aug 24, 2013, at 5:42 , Mathias Bynens math...@qiwi.be wrote:
To clarify: consider what the Identifier Identification strawman[1] or any
scripts that emulate similar behavior should do if Allen’s suggestion would
be implemented:
String.isIdentifierStart('\uD87E\uDC00'); // should
On Aug 6, 2013, at 10:24 , Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Aug 6, 2013 at 11:50 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
However, the [definition of `RangeError`][1] probably needs some updating in
that case:
Indicates a numeric value has exceeded the
I actually had ValueError in the 2011-10-31 draft of ECMA-402; the TC39 meeting
on 2011-11-16 decided against that.
http://wiki.ecmascript.org/lib/exe/fetch.php?id=globalization%3Aspecification_draftscache=cachemedia=globalization:working_draft_ecmascript_globalization_api_2011-10-31.pdf
On Aug 6, 2013, at 12:44 , Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I actually had ValueError in the 2011-10-31 draft of ECMA-402; the TC39
meeting on 2011-11-16 decided against that.
http://wiki.ecmascript.org/lib/exe/fetch.php?id=globalization%3Aspecification_draftscache
On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote:
Norbert Lindenberg wrote:
On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote:
This is unfortunate. It does answer Anne's question though, in an
unpleasant way: Date instances cannot be immutable; they can
On Jul 19, 2013, at 0:41 , Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Jul 17, 2013, at 20:29 , Brendan Eich bren...@mozilla.com wrote:
Norbert Lindenberg wrote:
On Jul 17, 2013, at 13:58 , Brendan Eichbren...@mozilla.com wrote:
No, *time* is stored as milliseconds
On Jul 17, 2013, at 13:58 , Brendan Eich bren...@mozilla.com wrote:
No, *time* is stored as milliseconds after the epoch in a number (IEEE
double).
A Date object includes position on planet and timezone politics (see
getTimezoneOffset).
No, it doesn't. Any time zone information used by
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
On Jul 17, 2013, at 16:59 , Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:42 PM, Brandon
On Jul 17, 2013, at 16:48 , Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote:
I'm still confused as to when it's correct for an API to return a Date
object.
At least in SpiderMonkey it's impossible to create Date objects that
On Jul 17, 2013, at 17:27 , Mark S. Miller erig...@google.com wrote:
This is unfortunate. It does answer Anne's question though, in an unpleasant
way: Date instances cannot be immutable; they can be at best readonly.
Despite lack of any authorization to track the user's position, Date
On Jul 13, 2013, at 12:37 , André Bargull andre.barg...@udo.edu wrote:
On 7/13/2013 8:48 PM, Andy Earnshaw wrote:
On Sat, Jul 13, 2013 at 1:05 PM, André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
Only exposing CanonicalizeLanguageTag does not seem useful to me
Looking at the discussion on
https://code.google.com/p/v8/issues/detail?id=90
it seems the V8 team is waiting for TC39 to tell them that they have to switch
to a stable algorithm.
An agenda item for the next meeting?
Norbert
On Jun 13, 2013, at 14:40 , Brendan Eich wrote:
Just confirming:
Minutes of last week's meeting of the TC39 ad hoc on internationalization are
now available on the meetings page:
http://wiki.ecmascript.org/doku.php?id=globalization:meetings
Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
In preparation for tomorrow's internationalization ad-hoc meeting, I reviewed
the
Text Segmentation strawman:
http://wiki.ecmascript.org/doku.php?id=globalization:text_segmentation
Some issues go beyond internationalization and into general API design question
- I'd appreciate input from the
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
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 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)
and usage
level.
Allen
On Mar 7, 2013, at 11:35 PM, Norbert Lindenberg wrote:
ECMAScript is used to implement a variety of tools that check code for
conformance with the ECMAScript specification, minimize it, perform other
transformations, or generate ECMAScript code. These tools
ECMAScript is used to implement a variety of tools that check code for
conformance with the ECMAScript specification, minimize it, perform other
transformations, or generate ECMAScript code. These tools have to be able to
recognize ECMAScript identifiers, taking the identifier specification and
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 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
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/Kolkata
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
)
-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 PM
To: es-discuss
Subject: Internationalization: Support for IANA time zones
I'm updating the ECMAScript
On Mar 1, 2013, at 6:39 , Andrew Paprocki wrote:
I found this note later in the spec:
NOTE It is recommended that implementations use the locale and calendar
dependent strings provided by the Common Locale Data Repository (available at
http://cldr.unicode.org/), and use CLDR “abbreviated”
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 changes,
On Mar 1, 2013, at 7:20 , Eric Albright wrote:
2) These names are canonicalized to the corresponding Zone name in the casing
used in the IANA Time Zone Database. Etc/GMT and Etc/UTC are canonicalized to
UTC. (The subtle differences between GMT and UTC probably don't matter to
users of
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
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
The 28 February 2013 draft of the ECMAScript Internationalization API
Specification is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
http://norbertlindenberg.com/ecmascript/intl.html
Best regards,
Norbert
___
The internationalization ad-hoc of TC 39 has already decided that edition 2 of
the ECMAScript Internationalization API will support IANA time zone names in
DateTimeFormat. Implementations will need to include best available information
on all time zones or use equivalent operating system APIs.
Using Jeff's tests, I don't see exceptions being thrown in any of these
browsers: IE 9 and the current versions of Safari on Mac/iOS,
Firefox/Chrome/Opera on Mac/Windows. I don't have IE 10.
I also checked the tests in directory 15.4.4.7 of Test262; they don't cover
these cases.
Adding
Actually, it's not just case that users want to ignore. In many use cases,
users search for something similar to their search string, and the definition
of similar can vary substantially. For example, an English speaker typically
wants San Jose to also match San José, especially when he doesn't
value is undefined.
2013/2/6 Norbert Lindenberg ecmascr...@norbertlindenberg.com
On Feb 6, 2013, at 12:14 , Nebojša Ćirić wrote:
Does the test:
intl402/ch11/11.3/11.3.2_1_a_ii.js
This tests the behavior of the function returned by
Intl.NumberFormat.prototype.format with various
On Feb 6, 2013, at 12:14 , Nebojša Ćirić wrote:
Does the test:
intl402/ch11/11.3/11.3.2_1_a_ii.js
This tests the behavior of the function returned by
Intl.NumberFormat.prototype.format with various values for the value
argument. We'd like the argument to be a number. The normal pattern for
for converting basically a
UTF-32 input to an isolated surrogate pair. No valid Unicode string could
contain that. So why support it?
-Shawn
-Original Message-
From: Norbert Lindenberg [mailto:ecmascr...@norbertlindenberg.com]
Sent: Wednesday, December 12, 2012 2:40 PM
To: Shawn
On Dec 26, 2012, at 15:35 , Mark S. Miller wrote:
On Wed, Dec 26, 2012 at 2:58 PM, David Herman dher...@mozilla.com wrote:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller erig...@google.com wrote:
Sorry, I'd completely forgotten about those earlier options. I am
arguing only the latter.
, Alexandre Morgaut wrote:
Great!
Is there already a planned test402 initiative (similar to test262)?
Regards,
Alexandre
On 12 déc. 2012, at 19:28, Norbert Lindenberg wrote:
István has informed me that the Ecma General Assembly today unanimously
approved ECMA-402, ECMAScript
Do you know what the people who talked to you mean by aware of UTF-16 code
units?
As specified, String.fromCodePoint, accepts all UTF-16 code units because they
use a subset of the integers allowed as code points (0 to 0x versus 0 to
0x10). For non-surrogate values, you get exactly
[mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Norbert Lindenberg
Sent: Wednesday, December 12, 2012 1:25 PM
To: Erik Arvidsson
Cc: es-discuss@mozilla.org
Subject: Re: String.fromCodePoint and surrogate pairs?
Do you know what the people who talked to you mean by aware of UTF-16 code
István has informed me that the Ecma General Assembly today unanimously
approved ECMA-402, ECMAScript Internationalization API Specification.
http://ecma-international.org/publications/standards/Ecma-402.htm
Norbert
___
es-discuss mailing list
On Dec 4, 2012, at 11:43 , David Bruant wrote:
Le 04/12/2012 20:25, Jason Orendorff a écrit :
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens math...@qiwi.be wrote:
My guess would be that in 99% of all cases where `String.prototype.length`
is used the intention is to count the code points,
I haven't looked into sort algorithms in a while - how much slower are the
fastest stable ones than the fastest non-stable ones?
I ran into the stability issue recently when implementing a function to
interpret HTTP Accept-Language headers [1]. The language tags in these headers
can have
There's nothing in the proposal yet because I intentionally kept it small. It's
always possible to add functionality, but we need some evidence that it will be
widely used. Pointing at Twitter doesn't quite help - it's possible that the
number that Twitter shows reflects some limitation in
Hi Roger,
Thank you for the feedback! It's always good to hear from developers actually
using or planning to use the API we're putting together.
I saw Addison's and your follow-up, but will reply to this message because it
has the meat of your feedback. Note that my proposal has been approved
On Nov 2, 2012, at 23:08 , Allen Wirfs-Brock wrote:
I'm now looking at the work to implement the refactoring of the internal
methods in section 8 and I see we are probably going to loose even more of
the section number correspondence with previous editions. This tempts me to
seize the
ECMAScript internationalization meeting
10/5/12, 10:20AM
Richard Gillam (invited expert), Nebojša Ćirić (Google), Norbert Lindenberg
(Mozilla), Eric Albright (Microsoft), Allen Wirfs-Brock (Mozilla), Jungshik
Shin (Google)
Timeline. We began with a discussion of the timeline
The 12 October 2012 draft of the ECMAScript Internationalization API
Specification is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
and due to popular demand also in HTML form:
http://norbertlindenberg.com/ecmascript/intl.html
This is the final draft
There was additional discussion of length in the context of the
internationalization API, and a decision at the July TC 39 meeting to Apply
ES6 rules to all functions in Internationalization API. [1]
By ES6 rules we meant what Allen had proposed [2] and what's in section 13.1 of
the ES6 draft:
String.prototype.localeCompare
Number.prototype.toLocaleString
Date.prototype.toLocaleString
Date.prototype.toLocaleDateString
Date.prototype.toLocaleTimeString
Intl.Collator
Intl.Collator.supportedLocalesOf
Intl.NumberFormat
Intl.NumberFormat.supportedLocalesOf
Intl.DateTimeFormat
. Kevin's counter-example would be a it hurts when
I do this! don't do it! thing.
/be
Norbert Lindenberg wrote:
String.prototype.localeCompare
Number.prototype.toLocaleString
Date.prototype.toLocaleString
Date.prototype.toLocaleDateString
Date.prototype.toLocaleTimeString
Intl.Collator
Are there any objections to removing the normalization property from the
Intl.Collator options object, and to documenting the associated kk Unicode
locale extension key as unsupported, in the first edition of the ECMAScript
Internationalization API? If so, please raise them by Tuesday, October
Ticket filed: https://bugzilla.mozilla.org/show_bug.cgi?id=798138
Norbert
On Oct 4, 2012, at 15:18 , Michael Dyck wrote:
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting to ping it.)
Any idea when it'll be back up?
-Michael
Up and running again.
Norbert
On Oct 4, 2012, at 16:21 , Norbert Lindenberg wrote:
Ticket filed: https://bugzilla.mozilla.org/show_bug.cgi?id=798138
Norbert
On Oct 4, 2012, at 15:18 , Michael Dyck wrote:
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting
The 3 October 2012 draft of the ECMAScript Internationalization API
Specification is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
This draft has the content that TC 39 approved on 18 September for submission
to the Ecma CC and GA.
Best regards,
Norbert
This list is good input for the meeting. As a reminder of smaller items that
didn't make it into edition 1.0, plus some possible enhancements, I also filed
some tickets:
, and a clear majority for change, the spec will remain as
approved at the meeting two weeks ago.
Thanks,
Norbert
On Sep 29, 2012, at 23:08 , Brendan Eich wrote:
Norbert Lindenberg wrote:
Last week TC 39 approved a standard defining three new built-in constructors
whose instances and prototype
It might be useful to list all the observable features to which valid instance
of might lead for a built-in BuiltIn.prototype, and check whether we want them
for new built-ins:
1) Object.prototype.toString.call(BuiltIn.prototype) returns [object BuiltIn].
True for ES5 objects, currently not
. The
discussion may also lead in the opposite direction, making the prototype a
simple object with just the specified methods.
Norbert
On Sep 29, 2012, at 23:08 , Brendan Eich wrote:
Norbert Lindenberg wrote:
Last week TC 39 approved a standard defining three new built-in constructors
whose
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully
operate on the object, at least as long as they don't modify the state.
True for ES5 objects, currently also true for ES Internationalization
objects. This means
On Oct 1, 2012, at 16:41 , Brendan Eich wrote:
Norbert Lindenberg wrote:
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully
operate on the object, at least as long as they don't modify the state.
True for ES5 objects
Last week TC 39 approved a standard defining three new built-in constructors
whose instances and prototype objects all have [[Class]] Object. Also, the
prototype objects are not constructed by their respective constructors, but
initialized by them, e.g., as Intl.Collator.call({}).
Are you
Hi Colin,
When changing the implementation of a standard built-in function that's defined
in the ECMAScript Language Specification, you should always check the
specification:
http://ecma-international.org/ecma-262/5.1/
In this case, it seems your extension of the accepted formats is allowed by
is to have correct era
support, which means there is no year zero: you have 2 AD, 1 AD, 1 BC, 2
BC,...
Mark
— Il meglio è l’inimico del bene —
On Thu, Sep 13, 2012 at 1:38 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
The output of Date.prototype.toLocaleString
On Sep 13, 2012, at 6:55 , Andrew Paprocki wrote:
and Explorer formats it as being in the year 1 BC. Safari calculates the
day
according to the Julian calendar, all others use the proleptic Gregorian
calendar.
That is very surprising to me. Can anyone comment on why Safari chose
that
ES5 section 15.9.1 specifies a number of operations to map time values
(measured in milliseconds from January 1, 1970, midnight UTC) to
year/month/day/hour/minute/second values, and the ECMAScript
Internationalization API specification section 12.3.2 mandates use of these
algorithms also for
1 - 100 of 231 matches
Mail list logo
