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.
I'm sorry to bother you again, but I've found a mistake in the conditions I previously reported for reproducing the bug. Additionally, while conducting further investigation, I found that the conditions can be simplified, so I'd like to revise my report accordingly. As of the time of posting this comment, the correct conditions for the bug to occur are as follows: - The year is less than 0 (i.e., BCE). - The year is a leap year (i.e., if year + 1 matches the Gregorian leap year rule). - The date is more than 59 + D days after January 1st of that year. - 59 is the number of days from January 1st to February 28th, inclusive. - D is the number of days by which the Julian calendar lags behind the Gregorian calendar. - D changes by 1 for each year where year + 1 is divisible by 100 but not by 400 — i.e., one of the three common years in the Gregorian 400-year cycle. Basis for revision: https://git.libreoffice.org/core/+/6d4f2dcc7cbba771e9d9b00de50368db4a88ef1b%5E%21 https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar#Julian_calendar_differences --- Side note: The mistake happened for the following reasons: - I lacked a proper understanding of how BCE dates are handled. - I based my thinking on a calendar starting at year 0, which is convenient for calculations and conditional logic.