[Libreoffice-ux-advise] [Bug 91758] dash delimited dates entered are not correctly interpreted as Y-M-D in specific cases

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=91758

V Stuart Foote <vstuart.foote at utsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |vstuart.foote at utsa.edu
          Component|ux-advise                   |UI
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #2 from V Stuart Foote <vstuart.foote at utsa.edu> ---
(In reply to Wolfgang Jäger from comment #0)
> ... Allowing for sloppy
> abbreviations may meet the expectations of some users. It's a mess
> nevertheless. If any abbreviation in dash delimited dates shall be accepted
> it should, however, be restricted to variants of Y-M-D formats without
> exception.
> 
> The present behaviour, as described, is error-prone including risks much
> exceeding the very small possible use of trying to adapt the "recognition"
> to  locales.

(In reply to Aron Budea from comment #1)
> ...
> However, what if it was more apparent for the user how their input was
> converted, or will be converted to a date? Is there a way to show this on
> the UI?
> 
> Dear UX team, can you consider ideas for making date input less error-prone?

Sorry, but we provide the Tools -> Options -> Languages "Date acceptance
patterns:" field to customize date input and CSV filtering in the exact format
desired as alternative to--or in addition to localization default.

Also, as noted the ISO 8601 formats are always honored. 

In sheet cells correctly cast to hold dates, the first example will enter
correctly as 2015-05-30 if a date pattern of D-M-Y is added to the field. 
Likewise the second will enter correctly when a pattern of M-D-Y is present.
Obviously, when working with data, user needs to be clear as to the
filter/input pattern they have set.

Meaning, it functions as intended enabling a user to manage their data and
adjust from defaults for their needs, while providing reasonable localized
defaults.

Would say NAB and otherwise won't fix.

>From the Help:

Date acceptance patterns

Specifies the date acceptance patterns for the current locale. Calc spreadsheet
and Writer table cell input needs to match locale dependent date acceptance
patterns before it is recognized as a valid date. Default locale dependent date
acceptance patterns are generated build time, but it is possible to add more or
modify them in this edit box.

Additionally to the date acceptance patterns defined here, every locale 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.

Syntax: Y means year, M means month, and D means day, regardless of
localizaton.

-- 
You are receiving this mail because:
You are on the CC list for the bug.