Our code is exercising this commit right now and it feels very, very strange that with the "short" date skeleton, we get these results:
"12/24/3" parses ⁉️"12/24/33" parses"12/24/333" does not parse"12/24/3333" does not parse
I understand this change for days and months. And I'm sure there are obscure use cases (archaeologists?) for whom parsing a single-digit year makes sense. But my guess is the vast majority of cases where globalize parsing is being used for e.g. form input validation, this is unwanted and frankly confusing behavior.
I'm not sure I read this thread correctly -- is there a way to disable the behavior where single-digit years now parse? Seems like this should be opt-in behavior for years, or at the very least an option to opt-out.
Our code is exercising this commit right now and it feels very, very strange that with the
"short"date skeleton, we get these results:"12/24/3"parses"12/24/33"parses"12/24/333"does not parse"12/24/3333"does not parseI understand this change for days and months. And I'm sure there are obscure use cases (archaeologists?) for whom parsing a single-digit year makes sense. But my guess is the vast majority of cases where
globalizeparsing is being used for e.g. form input validation, this is unwanted and frankly confusing behavior.I'm not sure I read this thread correctly -- is there a way to disable the behavior where single-digit years now parse? Seems like this should be opt-in behavior for years, or at the very least an option to opt-out.