Parsing APIs

[jzaefferer]

2020 Update: See #342 for further discussion.

Currently the spec has no APIs for parsing dates or numbers. Supposedly the response used to be "use a datepicker" when asking about date parsing. I'm wondering if that changed.

[srl295]

@jzaefferer I think the main issues may be:

• triaging for the 1st edition.
• parsing is not usually 1:1 (unlike format) therefore
  • parsing can require control of leniency
• from a UI point of view ( browserland ) a datepicker widget is often a better interface (less error prone) than parsing a box of free text, however, this of course does not handle all use cases.

In any event, I think that, unlike the way ICU currently does it with a symmetric object (input+output), it would be better to have a separate object for parsing rather than add a "parse()" function on the date or number objects.

[zbraniecki]

I agree with @srl295. Parsing dates especially feels like a very risky task with extremely high barrier for good user experience. Unless we can provide something that works for 95% cases, developers who will decide to use it will have to manually parse it anyway for when Intl API fails, and will probably come up with their own solution anyway. I'd leave it to specialized libraries.

[caridy]

Closing this issue by consensus, but if anyone wants to go for it, we are open to evaluate the concrete proposal.

[jungshik]

JFYI, v8 has v8Parse, but we may get rid of it soon pending the stat collection on it usage.

/cc @littledan, @Cira, @jungshik