-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Comments
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: moment/src/lib/create/from-string.js Line 22 in 7589bb8
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. |
ISO 8601 does suport simply form '201701' and '2017' |
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:
|
You know what, you're right. I have a copy, and for year+month, the basic form is 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 To summarize:
|
Hello! It's my first time contributing to opensource. Can I take this? :) |
Hopefully #4470 will fix the issue |
moment#4470) revert support for extended years [+/-YYYYYY], it needs more discussion and work
moment('2017-01')
is undocumented in the supported ISO strings, but is correctly parsed as2017-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.
The text was updated successfully, but these errors were encountered: