Created attachment 170134 [details]
testsheet with cells G51:G53 '0' on load

see C#0

Reproduced in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: d7ed130f537a81b900c55d222004cc9e88c0b355
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

and

Version: 5.3.0.0.alpha1+
Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c
CPU Threads: 4; OS Version: Linux 5.7; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group

@Eike, I thought you might be interested in this issue

still an issue in: 

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6e6e531b564cdc9d5b25287c215cdc5a1fcbb346
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

values calculated with rawsubtract(), cause of issue? but imho calc would / should load the values from file ... ???

Created attachment 171437 [details]
another sheet with the same issue

found that it's not a complete hard recalc needed, but already a recalc of cells E51:E53 with 'F9' triggers a correction of G51:G53 in 32183_testsheet_01_a.ods, 

in the new attachement 140722_testsheet_02_ori.ods cell A9 is shown as 
1970-01-01 T 00:25:00,99999 after load, even when corrected to 1970-01-01 T 00:25:01,00000 by 'F9', saved and reloaded, and despite it's mostly correct represented in the content.xml file as: 

<table:table-cell table:formula="oooc:=(ROUND(RAWSUBTRACT([.A$4]*86400;-ROUND([.B9]*[.A$3];1));1)+0.000000499999999)/86400" office:value-type="date" office:date-value="1970-01-01T00:25:01">
   <text:p>1970-01-01 T 00:25:01,00000</text:p>

Created attachment 172927 [details]
file_to_illustrate_the_effect_of_storing_rounded_values_harming_display_after_reload

Could produce a 'simple reproducer', and boil down the problem a little: 

With attached file you will 
- see a display as in screenshot attached to the next comment after a hard recalc (shift-ctrl-F9), 
- will get a saved file as in screenshot in second after this comment, correctly containing the value 1,77635683940025E-15 for cell B3, when saving the file, 
- but a display as in third after this comment showing '0' for B3 after load. 

In my opinion this bug is interesting/important as it could be the cause of many other 'save-load' problems and 'hard recalc neccessary' complaints. 

The causal error is, in my opinion, the interaction of three irregularities, 
- first, that for cell A3 the rounded 'UI-display-value' '8,13' is saved as float value and text, which differs from the (unfortunately wrong) calculation result '=A1 + A2', and 
- secondly, although it is turned off, some 'recalc on load' is performed, and
- third this recalc recalculates B3, while not! recalculating A3. can be checked with '=rawsubtract(A3;8,13) in A5, result '0' in fresh loaded file, changes to 1,7763~E-15 after a individual recalc of A3 (F9). 

I think I will change the title accordingly. 

And would be grateful for a code pointer, where are the display and store values calculated? (I'd like to try to extend the display values to 16 digits anyway, if only to make my work on cancellation and addition roundoff/on problems easier (the example comes from this work, a (decimally) wrong result of an addition which is only hidden but not corrected by calc's user interface)). 

(the calculation of 'value' and 'left' in cell B3 is not erroneous, i tried '=A1 + A2' in A4 and '=rawsubtract(A4;8,13) in cell B4 -> same behaviour, same fail.)

Created attachment 172928 [details]
display of the calculated values, A3 display-rounded by calc, B3 showing the deviation,

Created attachment 172929 [details]
rounded value for A3 and exact value for B3 stored in the saved file

Created attachment 172930 [details]
B3 showing wrong - recalculated? - value after reload

Created attachment 173078 [details]
file_showing_another_flavour_of_the_same_problem

this file is loaded / shown with seemingly correct content, but the value? loaded for B6 is now a real 0,30000000000000000000 instead of the correct calculation result of 0,30000000000000004~~~ 

resulting effects: recalc of C6 results in '0', and changes back to 5,55E-17 after any recalc of B6. 

B6 is stored in the content.xml file as: 

'table:formula="of:=  [.B4] +  [.B5]" office:value-type="float" office:value="0.3" calcext:value-type="float"><text:p>0,30000000000000000000</text:p>', 

changing that to: 

'table:formula="of:=  [.B4] +  [.B5]" office:value-type="float" office:value="0.30000000000000004" calcext:value-type="float"><text:p>0,30000000000000004000</text:p>' 

resulted in a little delay on recalc for C6, but the irritating effect is gone. 
thus evaluation of precise values in content.xml works, it's just the storing which harms? 

above scheme might be root cause for other save - load - recalc issues. injecting inaccuracies and ambiguities already on file load complicates understanding for users and debugging for supporters and developers. The referential integrity is undermined. The effect occuring rare and unpredictable makes that even worse. 

proposal: 
don't use the 'prettyfied' display values to save in file, but a string which uniquely identifies the fp double value valid for that cell, this sample needs 17 digits. 

(values in the 'weak precision ranges' ([0,5 .. 1[, [8 .. 10[ etc.) would be sufficiently identified with less digits, but not harmed by too many.) 

proposal II: 
do the same - storing the 'correct string' - for the 'text' of the cell, it will avoid irritations and we might need it in very near future when doing decimal correct calculations. 

if nobody want's to work on it, but somebody could give me a code pointer i'll give it a try ...