(I am writing in CAPS because someone suggested it in another post. I am not using CAPS to indicate yelling or frustration.) (The closest existing Post I found is 94187. It may or may not be helpful to reference.) I HAVE BEEN USING CALC SPREADSHEETS TO TRACK DATED INFORMATION. NORMALLY THE DATE FORMATS CORRECTLY WHEN THE CELL IS FORMATTED AS "Date". BUT I ENCOUNTERED A SPECIAL CASE WHICH DOES NOT. I DO NOT REMEMBER THIS OCCURRING BEFORE SO IT MAY COINCIDE WITH A RECENT UPDATE. IF I ENTER THE DATE 3/4/2016 IT SHOWS UP AS 3/4 2016. THE "3/4" APPEARS AS A SMALL FRACTION LEADING THE YEAR. IF I TYPE THE DATE EXPLICITLY AS "March 4, 2016" IT DISPLAYS CORRECTLY AS 3/4/2016. HOWEVER, THE ISSUE DOES NOT APPEAR WHEN I ENTER DATES BEGINNING WITH 3/5, 3/6, 3/7, OR 3/8 ALSO THE ISSUE APPEARS WITH 1/2/2016 APPEARING AS 1/2 2016. THE "1/2" APPEARS AS A FRACTION LEADING THE YEAR RATHER THAN A DATE. HOWEVER, THE ISSUE DOES NOT APPEAR WHEN I ENTER DATES BEGINNING WITH 1/3, 1/5, 1/6, 1/7, OR 1/8. THERE IS A FEATURE IN LibreOffice Writer THAT AUTOFORMATS SMALL FRACTIONS LIKE "1/2" AND "1/4". SO, I EXPECT THIS BUG PERTAINS TO A SIMILAR FEATURE IN LibreOffice CALC. HOWEVER, THIS SPECIAL FORMATTING IS APPEARING WHEN IT SHOULD NOT. A CELL FORMATTED FOR DATES SHOULD NEVER AUTOFORMAT TO FRACTIONS. Calc Version: 4.2.8.2 Build ID: 420m0(Build:2) OS: Ubuntu 14.04 Platform: x86 It is possible to work around this bug but it is annoying and can decrease productivity. I would be glad to have it fixed. Thank you for your assistance. Also, I don't have the most recent beta version of the software installed. So, please don't expect me to test for the problem on the most recent beta version.
The issue also appears with dates beginning with 1/4 such as 1/4/2016. There three different cases I am aware of where this problem appears: Dates beginning with: 1/2 Dates beginning with: 1/4 Dates beginning with: 3/4 There may be others I am not aware of.
*** Bug 98430 has been marked as a duplicate of this bug. ***
this is a duplicate of Bug 71974 and it's cause by autocorrect collisions. a workaround to resolve this issue is described here: https://bugs.documentfoundation.org/show_bug.cgi?id=71974#c4 I also strongly suggest you to upgrade to latest stable LibO release which is 5.0.5.2 the 4.2.8.2 release you are still using is totally obsolete and was released more than 1 year ago... since then thousands of bugs have been fixed and new features have been introduced. IMHO using the 4.2.8.2 is not the best idea *** This bug has been marked as a duplicate of bug 71974 ***