Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing less than complete ISO representations #3918

Closed
mattjohnsonpint opened this issue Apr 18, 2017 · 6 comments · Fixed by #5458
Closed

Parsing less than complete ISO representations #3918

mattjohnsonpint opened this issue Apr 18, 2017 · 6 comments · Fixed by #5458

Comments

@mattjohnsonpint
Copy link
Contributor

moment('2017-01') is undocumented in the supported ISO strings, but is correctly parsed as 2017-01-01 local time without giving a deprecation warning.

moment('201701') is the ISO 8601 basic form of the same representation, but this gives a deprecation warning, falls back to JS Date, and results in the entire number being interpreted as the year.

moment('2017') is also allowed under ISO8601, but we don't support it.

We should either fully support minimal representations less than a full date, or not support them at all, and we should document this either way.

@butterflyhug
Copy link
Contributor

Are you sure that '201701' is a valid ISO basic representation? We have a comment in the code that asserts YYYYMM (aka '201701') is not part of the standard:

// YYYYMM is NOT allowed by the standard

Assuming past-us is correct here, I think it would minimize confusion if we support and document '2017-01' and '2017', and explicitly document that '201701' was omitted from the standard.

@alburthoffman
Copy link
Contributor

ISO 8601 does suport simply form '201701' and '2017'
we should fix this one, and add test cases for this.

@butterflyhug
Copy link
Contributor

I repeat: are you sure about that?

I don't have a copy of the standard handy, but Wikipedia also asserts that year+month requires a hyphen alongside a plausible rationale:

By disallowing dates of the form YYYYMM, the standard avoids confusion with the truncated representation YYMMDD (still often used).

https://en.m.wikipedia.org/wiki/ISO_8601#Calendar_dates

@mattjohnsonpint
Copy link
Contributor Author

You know what, you're right. I have a copy, and for year+month, the basic form is YYYY-MM and the extended form is listed as "not applicable".

Year-only is allowed though. It is at least positive four digits 0000 - 9999, but can support five or 6 digits and negatives "by agreement"

We only support positive four-digit years with YYYY-MM-DD, so I think if we add year-only recognition it should match.

To summarize:

  • Document that we do support YYYY-MM as a recognized ISO8601 string
  • Add support for YYYY and document that too.

@ghost
Copy link

ghost commented Nov 9, 2017

Hello! It's my first time contributing to opensource. Can I take this? :)

@medinarkhov
Copy link
Contributor

Hopefully #4470 will fix the issue

medinarkhov added a commit to medinarkhov/moment that referenced this issue Apr 18, 2018
moment#4470)

revert support for extended years [+/-YYYYYY], it needs more discussion and work
ichernev pushed a commit that referenced this issue Apr 25, 2020
* [feature] add support for [YYYY] as ISO8601 format (issue #3918) (#4470)

* [feature] add support for [YYYY] as ISO8601 format (issue #3918) (#4470)

revert support for extended years [+/-YYYYYY], it needs more discussion and work
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants