Bug 51697

Hi.

There is also a major problem with date formatting in "Version 3.6.1.2 (Build ID: e29a214)".
OS = XP sp3, norwegian.

Whenever a cell is formatted as date (or not), Calc should threat the input as date. If I write "21.8" (without hyphens) the expected behaviour is that Calc should threat it as august 21 2012 - or whatever year it is.
Instead, Calc just treat the input as string equal to "21.8".

However if I write "21.8.12" then Calc threat the input as date as expected.

Cannot reproduce with LibO 3.6.3.2

Marking as WORKSFORME. Please try on latest stable release, if it's still a problem reopen as UNCONFIRMED.

Thanks for your patience and for helping us make LibO better for everyone :)

Oh my god this god closed!!!

The issue is still present in 4.0.2.2

Please don't play around with the severity/importance to try to raise awareness for your pet bug. Reverting change.

Also this bug was never confirmed by our QA team, moving to UNCONFIRMED.

Did I change the importance/priority? I don't remember and I don't see a history of that, but if I did, I wasn't "playing around", I was just changing the value to what I deemed correct. If you think users or bug reporters should not edit priority/importance settings, then you should restrict them to project maintainers or whomever you consider should be solely responsible of deciding that.
This is not my "pet bug", this is just an annoying bug as any other.


Regarding this:
> Also this bug was never confirmed by our QA team, moving to UNCONFIRMED.

Well, then why don't you TRY IT, so that you can either confirm or invalidate it?


Frankly, I think the person who marked this as "worksforme" simply didn't read my description carefully enough and did not follow the steps I provided to reproduce. I may be wrong about that, but please try again.

I'm under the impression that it got dismissed not because it couldn't be reproduced, but because the behavior is perhaps "as intended", in which case you need to realize that it is the wrong behavior.

Please follow the steps I provided to reproduce. If they don't reproduce the issue for you, please describe the outcome, and if it really is different from what I described, then let me know what additional information I need to provide about my setup that may be different from yours.

On Ubuntu with English locale, if I format a cell with Italian style date and input 02/01/12, it stays as 02/01/12.

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29

and

Version: 4.3.3.2
Build ID: 430m0(Build:2)

Can reproduce the behaviour with master (4.5.0.0alpha0+):
-locale is set to Ducht (nl-NL)
-cell format is set to MM/DD/YY
-when entering 1-2-12, 02/01/12 is displayed
-when entering 1/2/12, 02/01/12 is displayed

This behaviour is as I expected it to be.
The locale dictates how entered dates are handled (in the case of nl-NL, that is dd-mm-yy)
and the cell format dictates how a date value is displayed.

IMHO this is not a bug.
I leave it to Matteo or QA to decide if the status should be resolved/notabug.

> This behaviour is as I expected it to be.
> The locale dictates how entered dates 
> are handled (in the case of nl-NL, that is dd-mm-yy)
> and the cell format dictates how a date value is displayed.

Exactly. I thought I had made that pretty clear in the original report two years and a half ago.

To me it seem obvious that it is not the right behavior. It is counterintuitive that dates are not displayed the same way as they are entered.
I open a spreadsheet, see some dates, and the most obvious thing I expect is to be able to type them in the same format they are displayed, regardless of the locale of the computer where I'm opening the file.

I do understand that may be users who would prefer the current behavior. For example, if you happen to often enter data into spreadsheets that are not in your own language, and you want to enter the dates in the way you are accustomed to write them.

So in my opinion the best option would be to have a setting to deternine whether input is parsed according to current locale or according to cell format. Until then, it should be done according to cell format.

>  It is counterintuitive that dates are not displayed the same way 
> as they are entered.

I rephrase:

 It is counterintuitive that dates are not parsed the same way as they are displayed.

(In reply to matteo sisti sette from comment #8)

In comment #7 I gave two different entries for a date with a meaning. If the locale is DD-MM-YY and the cell display format is MM/DD/YY, how should 1-2-12 be interpreted?
Following the display format if the entered data exactly adheres to the display format and following the locale if not, is counterintuitive as well.

The present behaviour (use locale for input and display format for output) and is not the behaviour you want, but at least it's consistent.

I'm a developer, not a user interface specifier, so my view is biased towards 'does it work as designed'. (And my aim is to fix bugs.)
Quite possibly in your view the design should be changed. 
In that case you should set the bug importance not to normal, but to enhancement.

> In comment #7 I gave two different entries for a date with a meaning. If the locale is DD-MM-YY and the cell display format is MM/DD/YY, how should 1-2-12 be interpreted? Following the display format if the entered data exactly adheres to the display format and following the locale if not, is counterintuitive as well.

I get your point but i think there is a simple, intuitive AND consistent answer: 
- use the ORDER of months, days, year, regardless of the separators and number of digits, of the display format

(and of course, if the entered data only has a meaning if interpreted in a given way, use the one that has a meaning, but I think it already does that; except for a bug reported elsewhere where +1 is added to the year in some cases without a reason)

 
> Quite possibly in your view the design should be changed. 
> In that case you should set the bug importance not to normal, but to enhancement.

I don't agree with that. If what I'm proposing is an enhancement to a design that could arguably be improved for a better user experience, then it is an enhancement. But if the design is plain wrong, then it is as much of a bug as "not working as designed", only that the bug is in the design rather than in the code implementing it.


Of course it may be questioned whether the design is actually wrong. I'm saying it it. I hope someone from the specs teams (if there is one) reviews it.