Bug 131151 - Arithmetic error in Writer
Summary: Arithmetic error in Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.1 rc
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 127170
Blocks: Formula-Object
  Show dependency treegraph
 
Reported: 2020-03-05 11:28 UTC by Alexey
Modified: 2024-11-19 03:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
File with errors. (16.80 KB, application/vnd.oasis.opendocument.text)
2020-03-05 11:38 UTC, Alexey
Details
Error locations are shown. (140.46 KB, image/jpeg)
2020-03-05 11:41 UTC, Alexey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey 2020-03-05 11:28:26 UTC
Description:
An error occurs when using formulas in a table. Depends on the initial data in the yellow cells. See attachments.

Steps to Reproduce:
1.See attachments.
2.
3.

Actual Results:
See attachments.

Expected Results:
Arithmetic error.


Reproducible: Sometimes


User Profile Reset: Yes



Additional Info:
The problem is manifested in versions 6.2 and higher.
Comment 1 Alexey 2020-03-05 11:38:31 UTC
Created attachment 158404 [details]
File with errors.

In cell D17, the value should be 19:00.
Comment 2 Alexey 2020-03-05 11:41:18 UTC
Created attachment 158405 [details]
Error locations are shown.
Comment 3 Durgapriyanka 2020-03-05 16:10:38 UTC
Thank you for reporting the bug. I can confirm the bug present in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
	

But,not in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 4 Oliver Brinzing 2020-03-06 18:26:25 UTC
i think this issue is related to:

Bug 127334 (BrokenDateTimeSpec) - Regression: Incompatible changes in date/time arithmetic introduced between Version: 6.0.4.2 (x64) and version 6.2.6.2
Comment 5 Albrecht Müller 2020-04-16 17:04:20 UTC
... and also to 
Bug 127170 - Clarify clock time (HH:MM, MM:SS, ...) and duration time ([HH]:MM, [MM]:SS, ...) formatting in help; (ignore the MM month vs minute discussion) 

and to 

Bug 132083 - FORMATTING - Wrong date substraction in cell's operation
Comment 6 Albrecht Müller 2020-04-22 13:24:55 UTC
I think this bug cannot be solved without having clarified the issues discussed in bug 127170. That's why I moved the bug from "See also" to "Depends on".
Comment 7 Albrecht Müller 2020-04-22 16:44:05 UTC
The bug is also not in 

Version: 6.0.4.2 (x64)
Build-ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group

This seems to support Oliver Brinzings assumption that this bug is related to bug 127334. It is interesting in the context of the wall clock vs. duration format discussion. The error appears in column D. In this column you correctly use wall clock format HH:MM for a wall clock time.

Note that the value in line 8 column D should be exactly the same a the one in line 7 column E as it is just a copy of this value and the same format is used. Nevertheless the displayed values differ (16:49 vs. 16:50). 

I fear that this problem is related to a correct implementation of the specification of date and time arithmetic which makes it susceptible to tiny round off errors.
Comment 8 QA Administrators 2022-11-19 03:35:35 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2024-11-19 03:16:04 UTC
Dear Alexey,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug