Bug 169165 - Many cells in a large spreadsheet get zeroed when I do FILESAVE and reopen it (FILEOPEN).
Summary: Many cells in a large spreadsheet get zeroed when I do FILESAVE and reopen it...
Status: RESOLVED DUPLICATE of bug 165733
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
25.8.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-31 08:42 UTC by Eric Kvaalen
Modified: 2025-11-02 17:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
This is the spreadsheet with the problem. It's on Sheet1. Search for 30/12/1899. (21.09 MB, application/vnd.oasis.opendocument.spreadsheet)
2025-10-31 08:54 UTC, Eric Kvaalen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Kvaalen 2025-10-31 08:42:43 UTC
Description:
I have a large spreadsheet of 153,000 rows with dates in Column A. When I save it and later reopen it, a couple dozen of those dates have been changed to zero, which is 30/12/1899, and I have to fix them in order for a graph to be right.

Steps to Reproduce:
1. Save the spreadsheet
2. Reopen it
3.

Actual Results:
A couple dozen cells were zeroed.

Expected Results:
They should be the same as before.


Reproducible: Always


User Profile Reset: No

Additional Info:
The cells contained dates, not formulas.

I don't know whether I should add the spreadsheet as an attachment, since it's 21 megabytes, but I guess I have to.

I have another problem in this spreadsheet, which I mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=43983 but there has been no response.
Comment 1 m_a_riosv 2025-10-31 08:44:50 UTC
Please attach a sample file, reduce the size as much as possible without private information,
and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Comment 2 Eric Kvaalen 2025-10-31 08:54:24 UTC
Created attachment 203632 [details]
This is the spreadsheet with the problem. It's on Sheet1. Search for 30/12/1899.
Comment 3 Takenori Yasuda 2025-10-31 10:10:22 UTC
Could this perhaps be a duplicate of Bug 165733?
Comment 4 Eric Kvaalen 2025-10-31 11:41:16 UTC
Here are the dates that got zeroed in my spreadsheet:
17 Mar 1961 BC
17 Mar 1921 BC
16 Mar 1877 BC
16 Mar 1837 BC
15 Mar 1793 BC
15 Mar 1753 BC
15 Mar 1713 BC
14 Mar 1669 BC
14 Mar 1629 BC
.
.
.
2 Mar 61 BC
2 Mar 21 BC

My dates are separated by 10 days, so in the 20th century BC, I have March 17 in leap years only in 1961 BC and 1921 BC.

So it's similar to "165733 – Some BC dates cannot be saved In Calc". It refers to the same dates. I don't really understand the English of user "bestive" in that one, but it seems that his or her problem with these dates was different.
Comment 5 Eric Kvaalen 2025-10-31 16:19:00 UTC
I see now that the dates in question are dates which in the proleptic Gregorian calendar are February 29 -- "leap day". So some subroutine is trying to convert from the proleptic Gregorian to the Julian (which is what is displayed), and is messing up on every February 29th.
Comment 6 Takenori Yasuda 2025-11-02 05:43:43 UTC
> dates which in the proleptic Gregorian calendar are February 29
That line made me reconsider the conditions described in Bug 165733 — and it turns out they match exactly.

Although this report and Bug 165733 phrase the conditions differently, they are referring to the same thing: the bug occurs on the same specific dates.
Comment 7 Mike Kaganski 2025-11-02 13:49:12 UTC

*** This bug has been marked as a duplicate of bug 165733 ***
Comment 8 Mike Kaganski 2025-11-02 14:36:46 UTC
(In reply to Eric Kvaalen from comment #5)

Thank you Eric - I see it's you who found out what was causing the problem. Thanks!
Comment 9 Eric Kvaalen 2025-11-02 17:31:09 UTC
Thanks for fixing this!

Now I wish someone would fix https://bugs.documentfoundation.org/show_bug.cgi?id=43983, as I mentioned!
Comment 10 Mike Kaganski 2025-11-02 17:50:03 UTC

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