Steps to reproduce: 1. Open a calc document 2. Enter an OLE time value with a resolution > 10 ms like 45000.473994479200 3. Format Cell.., select Category Date, set Format Code to 'YYYY-MM-DD HH:MM:SS.000'. The date will be shown as '2023-03-15 11:22:33.123' 4. close and save the document 5. reopen the document 6. The time value has changed to '2023-03-15 11:22:33.120' = 45000.473994444400 Expected behaviour: Selecting a Date format should not change the value of the cell Root Cause: In case of cell format category Date the value is stored with a resoution of 10 ms only. Compare 'office:date-value="2023-03-15T11:22:33.12"' and '<text:p>2023-03-15 11:22:33.123</text:p>' Extract of content.xml after step 4 'close and save' <table:table-cell table:style-name="ce1" office:value-type="date" office:date-value="2023-03-15T11:22:33.12" calcext:value-type="date"> <text:p>2023-03-15 11:22:33.123</text:p></table:table-cell> <table:table-cell table:style-name="ce4"/>
Repro, but looking at bug 150049, I thought to ask Mike and Eike for their opinion on this. Arch Linux 64-bit, X11 Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 05f60be48a51a64ce99a7a7b62ae030002b16a14 CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 29 November 2023
Bug 158353 comment 3 shows a "value changes after save-and-reload", which is similar, maybe the same...
As comment 0 description says, the date+time is _stored_ already with an office:date-value truncated to 2 decimals, office:date-value="2023-03-15T11:22:33.12"
A side note, FWIW... (apologies for the slight OT/noise) In: 45000.4739944792 we have: 5 digits before the decimal separator 10 digits after the decimal separator i.e. a total of 15 digits. IIUC, Calc is not capable of considering additional digits. At some point or another, there will be some limit. Even if this report triggers some correction, some user might eventually ask for some additional digits/accuracy to be considered. * A date+time with serial number: 99999.0123456789 means a date+time of: 2173-10-13T00:17:46.667 * A date+time with serial number: 99999.9999999999 means a date+time of: 2173-10-14T23:59:59.999 and will be the last date+time with this same accuracy. * Since 2173-10-15, the date part of the serial value requires 6 digits, so the accuracy for the time part will already be lower than the current 10 digits. A kind of "2YK" problem of sorts, 150 years into the future by the time of this writing :-D. IMHO, users that need such accuracy for the time part of a date+time value would do themselves a favor by treating the time part by itself, and perhaps even as an integer numeric value, leaving the built-in date+time format aside.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c3f57487c9cc29d172121b178938cdb2a8adc7b Resolves: tdf#158265 Store more than 100th seconds precision in date+time It will be available in 24.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.
Pending review https://gerrit.libreoffice.org/c/core/+/160040 for 7-6
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7d79afebef281657a58cba065af0c5ba79a4e9e1 Resolves: tdf#158265 Store more than 100th seconds precision in date+time It will be available in 7.6.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.