Download it now!
Bug 30821 - [TABLE]: Default date format should be four-digit year
Summary: [TABLE]: Default date format should be four-digit year
Status: CLOSED DUPLICATE of bug 46448
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
Depends on:
Reported: 2010-10-13 00:50 UTC by martin f. krafft
Modified: 2015-02-19 17:09 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description martin f. krafft 2010-10-13 00:50:26 UTC
[This bug is with 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, at least for my locale. Even if I set, 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, which should have been done about 20 years ago. ;)
Comment 1 Cédric Bosdonnat 2010-10-13 01:40:44 UTC
Martin: Could you give some details about the locales for which to expect that default value?
Comment 2 martin f. krafft 2010-10-13 02:03:01 UTC

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.
Comment 3 Rainer Bielefeld Retired 2011-01-08 10:37:15 UTC
[Reproducible] with "LibreOffice 3.3.0 RC2 - WIN7  Home Premium (64bit) German UI  [OOO330m18 (build]". 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
Comment 4 martin f. krafft 2011-01-14 22:12:41 UTC
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.
Comment 5 Don't use this account, use 2011-01-17 03:11:17 UTC
What does Gregorian (vs. Julian?) calendar have to do with this?
Comment 6 martin f. krafft 2011-01-23 05:06:44 UTC
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.
Comment 7 Björn Michaelsen 2011-12-23 11:33:58 UTC
[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:

more detail on this bulk operation:
Comment 8 Rainer Bielefeld Retired 2011-12-26 00:19:37 UTC
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.

do you have an idea for a more flexible solution? May be some "Default Number Style" in the Styles (<f11>)
Comment 9 Florian Reisinger 2012-01-21 10:21:49 UTC
It seems to work nown(LibO 3,5rc1) Win7 x64
Comment 10 Florian Reisinger 2012-01-21 10:24:20 UTC
It seems to work now(LibO 3,5rc1) Win7 x64
Comment 11 Rainer Bielefeld Retired 2012-01-22 03:00:25 UTC
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

How did you test? Please attach a sample document!
Comment 12 Juetho 2012-09-06 14:21:38 UTC
Indeed, it doesn't work: LibO (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 ( 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).

Comment 13 Robert Großkopf 2012-09-06 15:31:15 UTC
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.
Comment 15 Jean-Baptiste Faure 2014-05-01 20:26:24 UTC
(In reply to comment #14)
> Does date acceptance patterns introduced in LO 3.6 are enough to close this
> report?
> 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
Comment 16 Jean-Baptiste Faure 2014-07-20 08:53:25 UTC
Set status back to NEW because that is a valid enhancement request.

Best regards. JBF
Comment 17 QA Administrators 2014-10-23 17:32:01 UTC
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:

There are also other ways to get involved including with marketing, UX, documentation, and of course developing - 

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
Comment 18 Alex Thurgood 2015-01-03 17:40:55 UTC
Adding self to CC if not already on
Comment 19 Eike Rathke 2015-02-19 17:09:05 UTC

*** This bug has been marked as a duplicate of bug 46448 ***