Bug 51697 - EDITING: Cell format for date is not taken into account when entering data
Summary: EDITING: Cell format for date is not taken into account when entering data
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2012-07-03 13:18 UTC by matteo sisti sette
Modified: 2021-08-20 16:58 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description matteo sisti sette 2012-07-03 13:18:47 UTC
Problem description: 

Steps to reproduce:
1. Right click on a cell, select "format cells"
2. For "Category" select "Date", and for "format" select "31/12/99"
3. Type into the cell:  02/01/12

Current behavior:
The date is interpreted according to the current locale. If the current locale is USA, it is interpreted as February 1 and it comes out displayed as "01/02/12"

Expected behavior:
The date should be interpreted according to the format that has been assigned to the cell. So since the cell is formatted as "31/12/99", it should be interpreted as January 2 and it would show up as you typed it.



Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Comment 1 Grobe 2012-09-26 17:31:38 UTC
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.
Comment 2 Joel Madero 2012-11-21 21:14:55 UTC
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 :)
Comment 3 matteo sisti sette 2013-08-15 11:48:42 UTC
Oh my god this god closed!!!

The issue is still present in 4.0.2.2
Comment 4 Joel Madero 2014-11-02 16:15:36 UTC
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.
Comment 5 matteo sisti sette 2014-11-02 16:40:44 UTC
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.
Comment 6 Buovjaga 2014-11-15 16:18:48 UTC
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)
Comment 7 Winfried Donkers 2014-11-25 11:13:03 UTC
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.
Comment 8 matteo sisti sette 2014-11-25 11:33:23 UTC
> 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.
Comment 9 matteo sisti sette 2014-11-25 11:34:17 UTC
>  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.
Comment 10 Winfried Donkers 2014-11-25 12:11:55 UTC
(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.
Comment 11 matteo sisti sette 2014-11-25 13:34:14 UTC
> 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.
Comment 12 QA Administrators 2015-12-20 16:06:02 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2017-01-03 19:46:00 UTC Comment hidden (obsolete)
Comment 14 mt 2018-10-29 21:52:23 UTC
The bug is still present.

Version: 6.1.2.1
Build ID: 1:6.1.2-0ubuntu1
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: en-US (en_US.UTF-8); Calc: group threaded
Comment 15 QA Administrators 2019-10-30 03:37:01 UTC Comment hidden (obsolete)
Comment 16 phoebe 2019-10-30 12:08:21 UTC
> To make sure we're focusing on the bugs that affect our users today, 
> LibreOffice QA is asking bug reporters and confirmers to retest open, 
> confirmed bugs which have not been touched for over a year.

This is a shitty way to handle bug reports.
Ïf you haven't touched a bug for over a year and have a reason to think it might have fixed itself, then you go and retest.
Otherwise you leave it open. Especially if it had already been confirmed, it should be considered to be still there until proven otherwise, not the other way around.
Comment 17 Buovjaga 2019-10-30 12:51:43 UTC
(In reply to phoebe from comment #16)
> > To make sure we're focusing on the bugs that affect our users today, 
> > LibreOffice QA is asking bug reporters and confirmers to retest open, 
> > confirmed bugs which have not been touched for over a year.
> 
> This is a shitty way to handle bug reports.
> Ïf you haven't touched a bug for over a year and have a reason to think it
> might have fixed itself, then you go and retest.
> Otherwise you leave it open. Especially if it had already been confirmed, it
> should be considered to be still there until proven otherwise, not the other
> way around.

Nah, not a shitty way by far. We have consistently gotten around 25% close rate for methodically retested reports in this way. This is mostly because many of the reports are duplicates. The reports are in no way in danger of closing.
Comment 18 phoebe 2019-10-30 14:54:14 UTC
Oh I see, my bad, I thought that was saying that the bug would be automatically closed after a given period of time if not retested and reconfirmed.