Issue 124807 - auto reformatting / input discarding issue unresolved for 6 years
Summary: auto reformatting / input discarding issue unresolved for 6 years
Alias: None
Product: Calc
Classification: Application
Component: configuration (show other issues)
Version: 4.1.0
Hardware: All All
: P3 Major with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2014-05-03 13:02 UTC by ilikeweirdstuffs
Modified: 2014-07-02 23:28 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.0
Developer Difficulty: ---

Date like text (8.56 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-07-02 23:24 UTC, Kay
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ilikeweirdstuffs 2014-05-03 13:02:29 UTC
This  issue has been around since 2008 as this bugtracker and other forums prove. This problem was confirmed and then forgotten about.
Strings of the format [number1]/[number2] get autoformatted into dates and furthermore the input gets changed.

-This is immensely annoying since spreadsheet programs like calc mostly work on a WYTIWYG principle. Having to type an extra character (specifically: ') just to get the program to use the input you're actually giving it is extremely inconvenient for the 21st century.

-OOo Calc replaces my string {2/8} with {41678} once i reset the format to be numerical again. A program deciding to discard user input and use something else instead, without an option to turn this behavior off is bugged. This "feature" is a bug.

-Some people would like to use Calc to make tables with not only a single string type in it. Calc deciding that it needs to change text alignment too because instead of a numerical string i typed an alphabetical string in this cell, can be a major annoyance.

-The date format XX/XX/XX is strictly speaking incorrect in two of the languages i use with OOo (German and Hungarian). Thus the program interpreting a {2/8} input as date is also grammatically wrong, because in these languages a slash separating  month, date and year is either extremely uncommon or simply incorrect.


1A) Most importantly and first of all: Calc needs a button to disable the automatic recognition of date strings.
2A) In future versions it would be helpful and not too difficult to implement to have checkboxes for what type of strings Calc should recognize.
2B) In future versions, along with the checkboxes mentioned above should come a submenu for each string type detailing which format Calc should use as a default format for all newly recognized strings of that type. (As already seen in the R-click > Format cells window)
2C) In future versions along with the string recognition submenu should come the Advanced options of defining how a certain string type should  and should not be recognized. (Thus being given the option to disable xx/xx registering as a date, and being able to set that only xx.xx.xx, xxxx.xx.xx and xx.xx.xxxx should be recognized)
Comment 1 ilikeweirdstuffs 2014-05-03 13:23:26 UTC
Additional Comments:
Problems with the "intelligent" input recognition and changing were one of the reasons i personally switched to OOo. A lot of people i have been talking to had the same opinion. Now OOo is heading down the same alley.

Basically, i would like any editor program to write exactly what i type, exactly with the settings i typed it with, by default.
If, and only if i explicitly state that i would like to use its wisdom on how to do and write things (by pressing a button when typing or clicking a radio button on program startup) should it make changes to what i typed in.
Having a program that thinks it knows what i want to type better than i do per default and not even having so much as an OFF switch for this behavior, is simply awful.
Comment 2 Rainer Bielefeld 2014-05-03 13:57:06 UTC
This is all well known and reported, for example
"Issue 44378 - AutoCorrect Changes Entered Value to Fraction in Date Field"
"Issue 90581 - Option to prevent auto completion of date"
So nothing new in this report, mark it as DUP.
May I ask you to read <> before you submit more reports?

*** This issue has been marked as a duplicate of issue 90581 ***
Comment 3 ilikeweirdstuffs 2014-05-07 15:27:03 UTC
I know that perfectly well.
a) it is not an exact duplicate of that issue, because i did not only address the /disabling/ of the /DATE/ completion in the report
-date string recognition disabling
-GUI addition to better manage ALL string recognition
-addition of string recognition settings to prevent FORMATTING issues
-local date format should have an effect on date recognition
b) That issue has been completely disregarded for the past 6 years. We had two entirely new versions of OOo since then. I wanted to somehow signalize that this has been swept under the rug for too long.
Comment 4 Kay 2014-07-02 23:24:22 UTC
Created attachment 83631 [details]
Date like text

Three column spreadsheet and effects of column formatting on processing.
Comment 5 Kay 2014-07-02 23:28:55 UTC
See sample 3 column spreadsheet. First column explicitly formatted as "text", second as "date", and third with default formatting. Entries for all columns were input exactly as the first column. It therefore seems possible by using "text" format for complete columns or individual cells to bypass the normal behavior of converting date-like entries to dates.

Not sure if this a defect. We would need to check the specs and/or discuss this further on "dev".