- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Mon, 19 May 2014 11:35:24 -0700
- To: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
- Cc: "Jasper St. Pierre" <jstpierre@mecheye.net>, Rick Waldron <waldron.rick@gmail.com>, WHAT Working Group <whatwg@lists.whatwg.org>, public-script-coord <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On 5/19/14, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> On 1/19/14, Norbert Lindenberg <ecmascript@lindenbergsoftware.com> wrote:
>>
>> On Jan 19, 2014, at 10:01 , Jasper St. Pierre <jstpierre@mecheye.net>
>> wrote:
>>
>>> On Sunday, January 19, 2014, Garrett Smith <dhtmlkitchen@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"); Should this be standardized here:
>>> > http://javascript.spec.whatwg.org/#date
>>> >
>>> > Any proposals for Date.prototype.format, ala strftime?
>>
>> The ECMAScript Internationalization API provides date and time
>> formatting,
>> with an API that's more abstract and better suited to localization than
>> strftime:
>> http://www.ecma-international.org/ecma-402/1.0/#sec-12
>> http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat
>>
>> Parsing date and time input was considered for the second edition of that
>> standard, but our impression was that most applications prefer
>> date-and-time
>> pickers, so we dropped parsing.
>>
> I was talking about formatting, not parsing. But now you're talking
> about formatting,
(I meant to say that you're talking about parsing).
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
Received on Monday, 19 May 2014 18:35:51 UTC