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.
This bug also reproduced in the following version. I think this might occur in versions even older than this one. Version: 5.4.7.2 Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 8; OS: Windows 6.2; UI render: GL; Locale: ja-JP (ja_JP); Calc: CL Note: It says Windows 6.2, but it's actually Windows 11.
(In reply to Takenori Yasuda from comment #4) > - D is the number of days by which the Julian calendar lags behind the > Gregorian calendar. Wait, let me rephrase that: - D is the difference between the Julian and Gregorian calendars.
There was a significant hint in Bug 169165, Comment 5. Thanks to this, I was able to describe the bug trigger conditions more clearly and concisely, without changing the actual conditions: - The date is in the BCE era. - It corresponds to February 29 in the proleptic Gregorian calendar. Note: The displayed date is in the proleptic Julian calendar. When these conditions are met, the serial value becomes 0, and the date shown is the one selected in Tools > Options > LibreOffice Calc > Calculate > Date. The specific time (hour, minute, second) does not affect this behavior.
*** Bug 169165 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/c/core/+/193302
(In reply to Takenori Yasuda from comment #7) Thank you: the work you performed, where you nailed it down to leap days, allowed to fix it easily.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/97bc8766e297c8d5c22b2f6d4bd7b6d7258782fb tdf#165733: fix leap year detection BCE It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/c96933d95f1eee1018f893dfc08d9b5d52891201 tdf#165733: fix leap year detection BCE It will be available in 25.8.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8-3": https://git.libreoffice.org/core/commit/0dc4cf8c5a8427b249eff0afb8851b9113b023c2 tdf#165733: fix leap year detection BCE It will be available in 25.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I found the same error in version 25.2.5.2. I created a file containing bestive's example dates. When I opened it with version 25.8.3.2 it showed the correct dates. So it seems the error occurred when the file is reopened, not when it is saved, which is good news for those who already entered their dates.