[This bug is with OpenOffice.org 3.2.1, but I am reporting it here since that seems more sensible] The default date format for a table cell in Writer seems to be dd.mm.yy, at least for my locale. Even if I set dd.mm.yyyy, I find that for new rows, the format often switches back to two-digit years. Surely, that's a bug in and of itself, but it could be elegantly fixed by defaulting to dd.mm.yyyy, which should have been done about 20 years ago. ;)
Martin: Could you give some details about the locales for which to expect that default value?
Hello, I am sorry for not providing these data up front. My locale is "German (Germany)", and the top-most entry in the date format list is "31.12.99". I think "31.12.1999" should be the default.
[Reproducible] with "LibreOffice 3.3.0 RC2 - WIN7 Home Premium (64bit) German UI [OOO330m18 (build 3.3.0.2)]". When I have selected Automatic Number Recognition, inserted a new table into a new document ant type "7.", the date will be completed to "7.1.11". I do not know whether everybody will be happy with "7.1.2011", a default setting might be the better way. IMHO low priority, I can't reproduce the new row formatting change problem
Come on, after Y2K, I am sure there will be more people unhappy with a two digit date default than the Gregorian right way of doing it.
What does Gregorian (vs. Julian?) calendar have to do with this?
Nothing really. I guess what I wanted to say was that the days of two-digit-years were over before the respective calendar was put to use. Nowadays we need four digits to correctly represent the year; setting the default to anything less is wrong and provides absolutely no benefit.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Status of this bug report has been modified wrongly by a bulk change. I doubt that this is a WRITER Table issue. AFAIK the default date number format is defined by 'Language settings -> Languages -> locale setting' and will be for all applications, and currently with YY. I am not sure whether all users will be happy with a change to YYYY. @András: do you have an idea for a more flexible solution? May be some "Default Number Style" in the Styles (<f11>)
It seems to work nown(LibO 3,5rc1) Win7 x64
It seems to work now(LibO 3,5rc1) Win7 x64
I can't confirm that "it works" with "LibreOffice 3.5.0 RC1 German UI/Locale [Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87] on German WIN7 Home Premium (64bit). My Test: 1. open new WRITER document from LibO start center 2. created new 3x1 table 3. Typed "1.1." into first cell > remained "1.1." because auto number recognition inactive 4. Menu 'Tools -> Options -> LibO Writer Table -> Input into Tables' all 3 checked 5. Typed "1.1." into second cell <TAB> > Result "01.01.12" due to report @Florian: How did you test? Please attach a sample document!
Indeed, it doesn't work: LibO 3.6.1.2 (Win7 Home Premium 64-bit, German UI). I miss 4-digit-years in following situations, e.g.: * Writer: Insert > Fields > Date * Writer: Insert > Fields > Other > Database Fields * Calc: Format > Cells > Numbers > Date * Base: Form Designer > Properties Date Field > Date Format In each situation, I have to set the date format manually. On the other side, I set the Windows default setting "Date (short)" in "region and language" to TT.MM.JJJJ (dd.mm.yyyy) and recommend: Either LibO calls these OS settings as its own default settings, or the LibO options will be extended: Tools > Options > Language Settings > Languages default formating in addition to "decimal separator": Date (short), Date (long), Time (short), Time (long). Jürgen
We could add a field in "Language settings → Languages → locale setting" where the user could set the default as he wants (two-digit → four-digit). So, for example, nobody, who will create forms in Base with many date-fields, must change the behaviour in every date-field, when he wishes four-digits for the year.
Does date acceptance patterns introduced in LO 3.6 are enough to close this report? http://erack.org/blog/archives/8-LibreOffice-date-acceptance-patterns.html http://erack.org/blog/archives/archives/18-Does-your-LibreOffice-locale-need-a-date-acceptance-pattern-for-incomplete-date-input.html
(In reply to comment #14) > Does date acceptance patterns introduced in LO 3.6 are enough to close this > report? > http://erack.org/blog/archives/8-LibreOffice-date-acceptance-patterns.html > http://erack.org/blog/archives/archives/18-Does-your-LibreOffice-locale-need- > a-date-acceptance-pattern-for-incomplete-date-input.html No, date acceptance patterns solve the question to know how strings can be interpreted as date, like in csv files import. Here the question is about how to show dates. Perhaps expert configuration could be used to set the default date format, but I did not find if there is already a property for that. Best regards. JBF
Set status back to NEW because that is a valid enhancement request. Best regards. JBF
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Adding self to CC if not already on
*** This bug has been marked as a duplicate of bug 46448 ***