Abstract: Calc's (and in Writer table) cell input now needs to match locale
dependent date acceptance patterns before it is recognized as a valid date.
Previously the number formatter's input scanner was very lax in what it
accepted as a "valid" date. All combinations of 2-3 numbers separated by '.'
'/' '-' or the locale's date separator even with blanks in between that somehow
could be interpreted as a date was accepted as such, which was especially
confusing with incomplete dates containing only 2 numbers that in many cases
were meant as textual input instead. For example
- In en-US locale, M/D is a valid date input to be interpreted as day of
month of current year. However, M/D/ and M.D. were accepted as well.
- In de-DE locale, D.M. is a valid date input to be interpreted as day of
month of current year. However, D.M and D/M and D/M/ were accepted as well.
In case of an input like 1.2 in a de-DE locale or others using '.'
separator, meant as some sort of textual numbering, this was extremely
annoying, it was interpreted as 1st of February of current year and the user
had to prepend a single quote / apostrophe to suppress date recognition.
Similar for 1.2.3 in locales that do not use the '.' date separator.
Now, during build time for each locale one full date acceptance pattern is
generated from the existing locale data's number format FormatElement
with formatindex="21" that is also used to edit dates, taking the DMY
order and the defined DateSeparator. For example, in the en-US locale
this generates M/D/Y from the MM/DD/YYYY FormatCode, and in the
de-DE locale D.M.Y from the DD.MM.YYYY code. For this to work correctly
the separator used in the FormatCode must match the DateSeparator element
defined in Separators. As for all rules there's one exception though
;) if the format code uses a different separator and that is one of the known
'-' '.' '/' separators, a second pattern is generated using the format's
separator. This as a generalized case for locales that for example may use an
ISO 8601 edit format, as hu-HU does, regardless what the date separator is
defined to.
Additionally to the date acceptance pattern every locale of course still
accepts input in an ISO 8601 Y-M-D pattern, and since LibreOffice 3.5
that also leads to the YYYY-MM-DD format being applied.
Localizers, HEADS UP please
If in your locale incomplete dates should be accepted or additional
patterns that vary from the generated full date pattern are needed, those are
to be defined in the locale data LC_FORMAT element for which a new
DateAcceptancePattern element exists, of which zero or more can occur
before the FormatElement elements. Currently only the following
patterns are defined as they are the only ones I knew were plausible:
- bg-BG, a trailing breaking or non-breaking space followed by lower case
or upper case Cyrillic letter GHE and a dot, as defined in the edit format
- D.M.Y г.
- D.M.Y г.
- D.M.Y Г.
- D.M.Y Г.
- de-DE, incomplete date
- en-US, incomplete date
- sl-SI, date separator dot plus space
For example see i18npool/source/localedata/data/en_US.xml
Happy date accepting :-)
Update: an updated list of locales and patterns is available in a newer blog post.
