A string parsing API accessible to the programmer (not just through Temporal.___.from()) was considered almost from the very beginning as a potential part of the Temporal (V1) proposal. Ultimately it was decided to be out of scope.
This issue captures the use cases and discussion in case a parser API is proposed in the future.
This feature would probably subsume #22.
Advantages:
These are the use cases that we became aware of during the development of the Temporal V1 proposal:
Impose stricter control on string inputs. e.g. require minutes to be specified in ISO time strings, or require the time to be included to be specified in a date/time string
Clarify user intent. e.g. differentiating Z strings vs. local+offset strings in ZonedDateTime.from
Process information not part of Temporal's data model. e.g., custom annotations.
Handle partially-invalid/partially-valid ISO strings. Temporal doesn't support this case today, because invalid ISO strings throw even if some parts are valid.
Handle ISO strings extended by mutual agreement of communicating parties. There are several of these extensions in ISO 8601, e.g., extended years longer than 6 digits, or more than 9 decimal places.
Generically parse ISO strings for use in non-Temporal code. In this case, the user wants a parser to chop up an ISO string into parts so they can do whatever they want with those parts (e.g. custom parsing, display to users, etc.) Temporal doesn't support this case today.
Validate a string without the overhead of creating a Temporal object. (#22).
Many programming languages have an ISO 8601 parser in their standard library, but they all either return the equivalent of a Temporal instance in that language, or an epoch time, or a normalized ISO 8601 string. Some third-party libraries provide a parser functionality:
A string parsing API accessible to the programmer (not just through
Temporal.___.from()) was considered almost from the very beginning as a potential part of the Temporal (V1) proposal. Ultimately it was decided to be out of scope.This issue captures the use cases and discussion in case a parser API is proposed in the future.
This feature would probably subsume #22.
Advantages:
These are the use cases that we became aware of during the development of the Temporal V1 proposal:
Previous discussions:
Concerns:
TBD
Prior art:
Many programming languages have an ISO 8601 parser in their standard library, but they all either return the equivalent of a Temporal instance in that language, or an epoch time, or a normalized ISO 8601 string. Some third-party libraries provide a parser functionality:
iso8601:parse_exactiso_8601(do not confuse withiso8601)Constraints / corner cases:
TBD