Description: Entering "1.1.29" will end in recognition of "1.1.2029". Entering "1.1.30" will end in recognition of "1.1.1930". This is contra-intuitive. I would jugest the recognition of the century 20 in both cases. Steps to Reproduce: 1. Enter "1.1.29" in empty field. 2. Enter "1.1.30" in empty field. Actual Results: 1. Recognition of "1.1.2029". 2. Recognition of "1.1.1930". Expected Results: 1. Recognition of "1.1.2029". 2. Recognition of "1.1.2030". Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Debian package version: 1:7.3.0~rc2-3 Calc: threaded
(In reply to selva from comment #0) > Description: > Entering "1.1.29" will end in recognition of "1.1.2029". > Entering "1.1.30" will end in recognition of "1.1.1930". > This is contra-intuitive. I would jugest the recognition of the century 20 > in both cases. LibreOffice is 11 years old. The code it inherits from OpenOffice.org is even older. Recognizing two-digit year "30" as 1930 may seem counter-intuitive now, it was probably rather intuitive 20 years ago. And keeping backwards compatibility is important. If you want "30" to be recognized as 2030 for your personal use, there is an option in "Tools > Options > LibreOffice > General > Year (Two Digits)" for exactly this purpose. => NOTABUG
Thanks for the tip with the workaround. Changing the year in "Tools > Options > LibreOffice > General > Year (Two Digits)" as suggested works as supposed when I click "OK". But clicking on the "Apply"-button is not working properly. The first click sets the year back to the old value. The second click sets the year to the new value.
Maybe it is not a bug in 2022, but it soon will be. So there will be a moment that we are forced to break the backwards compatibility in the next 8 years. This transition should not be made for a fixed year. Wenn it was coded, it was apparently seen as appropriate to have this transition a few decades in the future. That is what it should be dynamically. That should be based on the year a spread sheet was created, not to mess with existing documents. Also for people not expecting this behaviour and accidentally creating big problems (which will become more common as we near 2030), it would be good to produce a warning when years from two different centuries are in a spreadsheet while the date format specifies to format the year in two digits.