https://bugs.documentfoundation.org/show_bug.cgi?id=150288
Eike Rathke <er...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #15 from Eike Rathke <er...@redhat.com> ---
One problem seems to be that a locale's implicit full date acceptance pattern
internally is always considered first, so if for en-US the patterns were set to
D/M/Y;D/M then while parsing input it becomes M/D/Y;D/M/Y;D/M so 31/8/22 is
accepted only with D/M/Y but 1/8/22 already with M/D/Y.
That probably should be fixed and the implicit pattern not be evaluated if the
specified Date Acceptance Patterns don't say so. I'd guess that first was done
to prevent users to shoot themselves in the foot as patterns completely not
matching the locale's patterns somehow don't make sense, but you can't have
both.
Apart from that, the following occurs:
First, date input is tried to be matched against the Date Acceptance Patterns
(including the locale's implicit full pattern). Second, if that does not match
a valid date and the input cell is formatted to a date already then the input
is tried to be matched against the format's locale's default date acceptance
patterns. So here for the explicit pt-BR locale the default patterns are
D/M/Y;D/M .
For case #1, that is first try M/D/Y;M/D then for 1/8/22 the current locale's
M/D/Y and for 31/8/22 of the format's D/M/Y is successful.
For case #2, that is try M/D/Y;D/M/Y;D/M (with the implicit full pattern) that
is successful for both, again with M/D/Y and D/M/Y.
For case #3, that is try D/M/Y;D/M that is successful for both with D/M/Y.
So even if evaluating the implicit pattern would be removed, case #1 with the
then resulting first M/D/Y;M/D then D/M/Y;D/M may still result in unexpected
but correct behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.
