Description: I found that some BC dates in LibreOffice 25.2 could not be saved When the "Paste" operation is used to fill in the cell, it will be displayed as "1899-12-30 00:00:00". After manual correction, save and exit. When the table file is opened again, they will become the error status of "1899-12-30 00:00:00" However, if it is stored as Double, it can be referenced in the form of a formula in the cell (for example: "=D2"), And set the display format to date, which will not restore to the error value after the second opening after saving Note: I use version 25.2. I haven't tested other versions. I don't know if this problem also exists. Thank you very much. I use LibreOffice every week. It's great!!! The list of problems I found is as follows: -1517-03-14 20:39:09 -1381-03-12 04:49:14 -1229-03-11 08:48:24 -1153-03-11 01:31:43 -1077-03-10 13:17:58 -0925-03-09 20:14:03 -0485-03-05 18:38:01 -0409-03-05 22:13:10 -0189-03-03 06:03:03 Steps to Reproduce: I have described in detail above. Actual Results: 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 1899-12-30 00:00:00 Expected Results: -1517-03-14 20:39:09 -1381-03-12 04:49:14 -1229-03-11 08:48:24 -1153-03-11 01:31:43 -1077-03-10 13:17:58 -0925-03-09 20:14:03 -0485-03-05 18:38:01 -0409-03-05 22:13:10 -0189-03-03 06:03:03 Reproducible: Always User Profile Reset: No Additional Info: This is a serious problem, which will lead to the rework of last week's work, and such data loss is difficult to find in the massive data. Please notify me after solving the problem. Thank you!!! wtshuang@qq.com Lee.
Thank you for reporting the bug. I can confirm that the bug is present in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 894563ee0e4032019623a97c313af3d833863b1f CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I confirmed that the bug is reproduced in both normal mode and safe mode. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo Furthermore, it appears that the time component is likely unrelated to this bug. When I removed the time part from the given datetime and tested under similar conditions, the same bug occurred. After further investigation of dates other than the provided one, I discovered that the bug occurs on dates with the following characteristics: - Dates in the BCE era. - Dates belonging to years that are exactly one year earlier than a leap year. (Note: In the BCE timeline, "past" refers to a numerically smaller year (e.g., for –1000, the "past" would be –1001) and "future" refers to a numerically larger year (e.g., –999).) - Dates that occur 60+n days after the New Year’s Day of that year. - Here, n starts at 1 and increases by 1 each time a year that is divisible by 4 but not by 100 is encountered when looking backward from the present.
(In reply to Takenori Yasuda from comment #2) > - Here, n starts at 1 and increases by 1 each time a year that is divisible > by 4 but not by 100 is encountered when looking backward from the present. Sorry! I made a mistake in writing. It's a year that is divisible by 4 and 100 but not by 400. In other words, it's an exceptional common year that occurs 3 times every 400 years according to the leap year definition. The correct version is as follows. - Here, n starts at 1 and increases by 1 each time a year that is divisible by 4 and 100 but not by 400 is encountered when looking backward from the present.