Bug 68121 - Wrong default year (next instead of current) if year omitted and date inserted as 31/12
Summary: Wrong default year (next instead of current) if year omitted and date inserte...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-14 19:37 UTC by matteo sisti sette
Modified: 2014-06-01 20:30 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
fvwsdvw (101.86 KB, image/png)
2013-09-18 23:57 UTC, matteo sisti sette
Details
wdfqwefqwef (81.81 KB, image/png)
2013-09-18 23:57 UTC, matteo sisti sette
Details

Note You need to log in before you can comment on or make changes to this bug.
Description matteo sisti sette 2013-08-14 19:37:23 UTC
1. Choose a date cell
Type: 20/8 (omitting the year)
Press Enter
Check result
2. Now  type: 8/20 (omitting the year)
Press Enter
Check result


Expected result: In both cases, should take the value 2013/08/20, i.e. 20th of august of 2013, defaulting to the current year (we are in 2013 at the time of reporting this bug).

Observed result:
In case 1 it takes the value 14th of august of 2014, i.e. next year. Nonsense.
In case 2 it behaves as expected, taking 2013 as the default year
Comment 1 matteo sisti sette 2013-08-14 19:39:08 UTC
I meant it takes the value 20 of august, not 14 of august.


AAARRRRGGGGGHHHHH when will this shit allow us to edit our reports?!?!?!?! I hate it!
Comment 2 retired 2013-08-15 09:39:08 UTC
Hi Matteo, I cannot reproduce this problem on OS X 10.8.4, LO 4.1.1.1.

What date format are you setting the cell to? I've set a cell to http://cl.ly/image/0n1G2L31173i and then entered 1. and 2. from your description. All I see is exactly what I entered.

But maybe I'm missing something? Could you provide more detailed steps on how to reproduce please?
Comment 3 matteo sisti sette 2013-08-15 11:37:17 UTC
The cell format is set as date 31/12/1999

But I can reproduce the issue also with format 31/12/99

What do you mean by "I see exactly what I entered"? Did you omit the year? If so, if you are seeing is exactly what you have entered you are experiencing a different bug, as you would be seeing a date without year.
Comment 4 matteo sisti sette 2013-08-15 11:40:50 UTC
Note that the way the date is interpreted when you enter it, is independend from the format of the cell - that is a separate bug, which I have already reported: that is, input should be interpreted according to the cell format but it always interpreted as m/d/a unless the numbers are outside sensible ranges; that's why I test this issue with values such as 20/8 to avoid extra noise
Comment 5 matteo sisti sette 2013-08-15 12:09:17 UTC
Actually, this issue only happens when the number of day is >12

That is:
-Enter 3/4
 => get 4th of march 2013, as "expected" (given bug 51697)
-Enter 4/3
 => get 3rd of april 2013 as "expected" (given bug 51697)
- Enter 8/20
 => get 20 of august of 2013 as expected (only reasonable outcome)
- Enter 20/8
 => get 20 of august of 2014 *nonsense
Comment 6 m.a.riosv 2013-08-17 13:33:48 UTC
Hi Matteo, enter dates is more restrictive in the last version.
Please verify you options in:
Menu/Tools/Options/Language Settings/Languages, there is an option for Date acceptance pattern.

In any case are needed your settings there to try in reproduce you issue.

See also:
http://erack.org/blog/archives/archives/archives/18-Does-your-LibreOffice-locale-need-a-date-acceptance-pattern-for-incomplete-date-input.html
Comment 7 matteo sisti sette 2013-09-18 17:18:36 UTC
Let me know what files I can look for and upload so that you can examine all my current settings and investigate the issue.

What is sure is that I observe the behavior i have described and, whatever the settings are, that behavior is wrong. Or, if it is the expected behavior under certain settings, then those settings are wrong and they are the default, since I haven't touched them.
Comment 8 m.a.riosv 2013-09-18 19:47:56 UTC
Did it happen with a file from scratch?
In this case what are the options in?:
Menu/Tools/Options/LibreOffice Calc/Calculate - Date.
Menu/Tools/Options/Language settings/Language - Locale setting.
Comment 9 matteo sisti sette 2013-09-18 23:57:07 UTC
Created attachment 86115 [details]
fvwsdvw
Comment 10 matteo sisti sette 2013-09-18 23:57:39 UTC
Created attachment 86116 [details]
wdfqwefqwef
Comment 11 matteo sisti sette 2013-09-19 00:08:02 UTC
Both from scratch and with existing files.

See the settings in the screenshots.

I enter "20/8" and it is interpreted as "20 aug. 2014".

By the way, what are the three options under "Date" in the "Calculate" settings supposed to mean?!?! They should be more clear.
Choosing between "12/30/1989" and "01/01/1900" and "01/01/1904" means absolutely nothing to me. I guess the programmer who wrote the application can understand it.
Comment 12 m.a.riosv 2013-09-19 02:23:59 UTC
With the locale English-US like your.
When I enter 20/8 is entered as text not as date.
When I enter 8/20 is correctly interpreted as 08/20/13

I you enter TODAY() in a blank cell, what date do you see?
Comment 13 m.a.riosv 2013-09-19 03:10:58 UTC
Sorry Matteo, the practice is someone else change the status to NEW when confirm the bug, and for now it is not the case.

Have you try resetting the user profile?, sometimes solve strange issues.
https://wiki.documentfoundation.org/UserProfile

Or try upload to 4.0.5.2
http://downloadarchive.documentfoundation.org/libreoffice/old/

A couple of link to learn more about how dates are handle in spreadsheets:
https://help.libreoffice.org/Calc/Date_and_Time_Functions
http://www.cpearson.com/excel/datetime.htm
Comment 14 matteo sisti sette 2013-09-19 11:10:07 UTC
(In reply to comment #12)
> With the locale English-US like your.
> When I enter 20/8 is entered as text not as date.
> When I enter 8/20 is correctly interpreted as 08/20/13

Me too, on a fresh virgin cell.
But if I previously format the cell as a date (no matter what specific date format) then I experience the behavior I described.
Did you format the cell as date????


> I you enter TODAY() in a blank cell, what date do you see?
I see "TODAY()", but I guess you mean if I write =TODAY(), in which case I see 
09/19/13


I'm eager to learn a lot about how dates are handled, but there is a bug here, because interpreting 8/20 as augusth 8th 2013 and 20/8 as august 8th 2014 doesn't make any sense under any kind of settings.
Comment 15 QA Administrators 2014-05-17 00:34:31 UTC
Dear Bug Submitter,

Please read the entire message before proceeding.

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 16 QA Administrators 2014-06-01 20:30:27 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO