TODO: Create APIs for parsing and formatting

[maggiepint]

How do we want to handle date parsing? Is it part of this proposal? 402? Some of both depending on if the date is ISO8601/RFC2822 or a local format?

Should there be a separate parsing object that returns a 'parsed date' object?

[apaprocki]

Feedback from Bloomberg POV:

We currently only rely on parsing the RFC3339 style ISO8601 profile string (e.g. "1985-04-12T23:20:50.52Z"). (We do this using up to microsecond resolution in the time-secfrac portion) Ad-hoc parsing of the other string formats usually just leads people down paths we wished they wouldn't go down, so it would not be missed if parsing only supported RFC3339 profile and pushed other parsing to other libraries.

We do not have any need for a "parsed date" object and I think it might just serve to confuse people. I'd go so far as to say that most C/C++ application code I've come across that decides to use libc struct tm API should instead be using existing higher-level library interfaces. Perhaps people reached down to struct tm because it was familiar or they didn't find documentation for higher-level libraries, but it certainly allows for a much higher chance for error when people start assembling/formatting the parts themselves instead of a well-tested interface. If the API surface allows for the conversions that are needed and ECMA402 provides necessary formatting, it wouldn't be helpful.

[Turbo87]

I tend to agree that ISO8601 parsing is most important if we want to have any parsing at all built-in. Building any other parsing on top of it should likely be delegated to libraries since there is essentially an infinite amount of things that people might want to parse and it seems impossible to handle all of that in a native implementation.

[apaprocki]

I think it would be important to call out if only the RFC3339 subset is supported from a spec point of view. Unless engines have consensus that something like ICU will be used across the board, I don't think it is reasonable to support all the various formats ISO8601 supports.

[simonbuchan]

I mentioned Intl.DateTimeFormat in #42, which seems relevant for the formatting side.
I assume any parsing spec added to ECMA should apply there to? E.g. DateTimeFormat.prototype.parseToInstant(string): Instant or Instant.parse(string, DateTimeFormat): Instant

[maggiepint]

I think the consensus here is that this proposal will handle ISO8601 and other format will for now have to be handled at later times. Closing this for the sake of being able to understand active issues.