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

[bugzilla-daemon]

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

Eike Rathke  changed:

   What|Removed |Added

   Keywords|needsDevEval, needsUXEval   |
 Status|NEW |ASSIGNED
   Hardware|Other   |All
   Assignee|libreoffice-b...@lists.free |er...@redhat.com
   |desktop.org |
   Severity|enhancement |normal

--- Comment #9 from Eike Rathke  ---
(In reply to Wolfgang Jäger from comment #6)
> In a locale (say English (USA)) "recognising" "5-12-14" as meaning
> 2014-05-12 an 
> input of "5-13-14" MUST be interpreted as 2014-05-13.
I'd rather say accepting 5-12-14 as date 2014-05-12 in an en-US locale without
modified date acceptance patterns (does not contain M-D-Y) is a bug. What is
actually happening here is that the input first is recognized as "slightly
possible ISO date input (where year would be 5)" but the end check rightly
fails and then the en-US MDY order is applied and the date accepted anyway as
05/12/14, which is wrong. Similar wrong for other locales, eg. in de-DE the
numbers are applied to a DMY order, resulting in 05.01.14, wrong again.

For an input of 5-13-14 already the "might this be an ISO date" check fails
because there's no month 13 and if the input does not match a date acceptance
pattern correctly does not result in a date.

Taking.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

Heiko Tietze  changed:

   What|Removed |Added

   Keywords||needsDevEval
 CC||er...@redhat.com
  Component|UI  |Calc

--- Comment #8 from Heiko Tietze  ---
(In reply to Wolfgang Jäger from comment #7)
> Will there be an opportunity to discuss the topic somewhere without writing
> reports, messages, comments, whatever most likely to no effect at all. It's
> all too narrow, and often misunderstandings cannot be expelled.

You are very welcome to the design meetings, at the IRC channel, and on
Telegram.
https://wiki.documentfoundation.org/Design

But your report is clear to me (as native German who prefers English UI it's
always 'surprising' how numbers are converted). On the other hand, Stuarts
reply is also reasonable. And we will not change how numbers are converted. And
actually there are plenty of functions to deal with datetime.

What I could imagine is better feedback. When you insert 5-1-15 and press Enter
the text could fade into a grey M-D-Y (depending on how it works) that fades
into the final Jun/01/20015 (or whatever). Eike, what do you think?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

--- Comment #7 from Wolfgang Jäger  ---
(In reply to Heiko Tietze from comment #5)
> ...(In reply to V Stuart Foote from comment #4)
> 
> Your explanation wrt. to the bug is thorough -> NAB.
> 
> What I could imagine, however, is more transparency for the conversion
> process. AFAIR the cells with converted content gets a small visual
> indicator in Microsoft Excel. And perhaps sometimes the conversion is
> unwanted, so being able to undo would be nice. But these are other questions.

Pointing to my above comment I object against "-> NAB".

The huge field of "recognition" and related questions of formatting,
localisations, and automatic conversion is completely messed up imo. This is a
statement about spreadsheets genarally, not about LibO / AOO specifically. 

Will there be an opportunity to discuss the topic somewhere without writing
reports, messages, comments, whatever most likely to no effect at all. It's all
too narrow, and often misunderstandings cannot be expelled.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

Wolfgang Jäger  changed:

   What|Removed |Added

 CC||j...@psilosoph.de

--- Comment #6 from Wolfgang Jäger  ---
One more comment on the example "5-13-14" from my original report more than two
years ago:

In a locale (say English (USA)) "recognising" "5-12-14" as meaning 2014-05-12
an 
input of "5-13-14" MUST be interpreted as 2014-05-13. in fact this input is NOT
recognised as a date at all but taken as text. The askbot question I mentioned
in the original report was caused by this behaviour under English (USA) locale
which is clearly a bug at least in the sense of being intolerably illogical. 

In a locale (say English (UK)) "recognising" "5-12-14" as meaning 2014-12-05 an
input of "5-13-14" MUST NOT be accepted as text, but must result in an error
message. There is no justification to regard the one input as a date and the
other one as a text without notice. Inputters are fallible!

I just tested the askbot case again setting my LibO V5.4.0.3 to English (USA)
locale (under English (UK) user interface). 

I would suggest to not leave it at "Happy to leave this open for now, see if
there is further comment." This is further comment - and I am not affected nor
aggrieved personally.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

--- Comment #5 from Heiko Tietze  ---
(In reply to V Stuart Foote from comment #4)
> Happy to leave this open for now, see if there is further comment.

Your explanation wrt. to the bug is thorough -> NAB.

What I could imagine, however, is more transparency for the conversion process.
AFAIR the cells with converted content gets a small visual indicator in
Microsoft Excel. And perhaps sometimes the conversion is unwanted, so being
able to undo would be nice. But these are other questions.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

--- Comment #4 from V Stuart Foote  ---
Happy to leave this open for now, see if there is further comment.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

--- Comment #3 from Aron Budea  ---
Thank you for the detailed explanation Stuart, set the status of the report as
you see fit.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

V Stuart Foote  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||vstuart.fo...@utsa.edu
  Component|ux-advise   |UI
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from V Stuart Foote  ---
(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 -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 the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

[bugzilla-daemon]

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

Aron Budea  changed:

   What|Removed |Added

   Keywords||needsUXEval
 CC||ba...@caesar.elte.hu,
   ||libreoffice-ux-advise@lists
   ||.freedesktop.org
  Component|Localization|ux-advise

--- Comment #1 from Aron Budea  ---
I understand your concerns, and can see this being a problem. However,
unfortunately the suggested behavior would cause a lot of annoyance and
confusion for users in different countries where a different format is used
instead of Y-M-D. Not only because they aren't used to it, but also because a
lot of different programs use locale-dependent date conversions.

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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs