You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: