Bug 130276 - libreoffice 6.4.0.3 calc, regression, entering 0:0:110 wont resolve into minutes and seconds
Summary: libreoffice 6.4.0.3 calc, regression, entering 0:0:110 wont resolve into minu...
Status: CLOSED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2020-01-30 04:41 UTC by Getafix
Modified: 2020-02-04 13:12 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Getafix 2020-01-30 04:41:33 UTC 
Description:
libreoffice 6.4.0.3 calc, regression, entering 0:0:110 wont resolve into minutes and seconds

Steps to Reproduce:
1. Entering 0:0:110 in calc used to get converted to 0:1:50 in older versions but has stopped doing so in 6.4.0.3
2.
3.

Actual Results:
0:0:110 remains 0:0:110

Expected Results:
0:1:50


Reproducible: Always


User Profile Reset: No



Additional Info:
This is a Regression
Comment 1 Kevin Suo 2020-01-30 10:51:35 UTC 
I confirm reproducing this behaviour, bug I am not sure whether this is a bug. 

Bibisected to range:
https://cgit.freedesktop.org/libreoffice/core/log/?id=d639f40886c89daee453a42e247ae657517f5504&qt=range&q=06b01f73a2d0cc5b6a1c86942e28b1ce7b37bd91..4444d5dbe7dba90ccfb0a9eeed36be0abfdd1854

Within which the following commit may have changed the behaviour:

commit d639f40886c89daee453a42e247ae657517f5504
Author: Eike Rathke <erack@redhat.com>
Date:   Sat Oct 19 11:05:27 2019 +0200

    We don't support leap seconds, but.. accept as input anyway


@Eike Rathke: Is this designed, or is it a bug?
Comment 2 m_a_riosv 2020-01-30 22:26:21 UTC 
Confirmed
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 1446e097e76669c0d7749ec0f8918606d3cc4c28
CPU threads: 4; OS: Windows 10.0 Build 19551; UI render: Skia/Vulkan; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: CL

Regression from:
Version: 6.2.8.1 (x64)
Build ID: 815fe723fb0e60e4a39ff860f907cc63980a0232
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc:
Comment 3 Eike Rathke 2020-02-04 11:05:34 UTC 
(In reply to Kevin Suo from comment #1)
> Within which the following commit may have changed the behaviour:
More likely it's

    commit 7d72b9d34c1183b7471a7a97c007aba10de2d27e
    Author:     Eike Rathke <erack@redhat.com>
    CommitDate: Fri Oct 18 23:44:09 2019 +0200

	Input with subsequent part greater than 59 is not time or duration
	
	Like 1:123 or 1:1:123 is text, but 123:1 or 123:1:1 is a duration.


And yes, that's on purpose.
Comment 4 m_a_riosv 2020-02-04 11:10:54 UTC 
Clear, thanks.
Comment 5 m_a_riosv 2020-02-04 11:17:52 UTC 
Sorry for the mistake, it's also clear in the help.
https://help.libreoffice.org/6.4/en-US/text/scalc/guide/numbers_text.html?DbPAR=CALC#bm_id3145068
"If only a time string is given, it may have an hours value of more than 24, while minutes and seconds can have a maximum value of 59."
Comment 6 Eike Rathke 2020-02-04 13:12:05 UTC 
That help text is unrelated though, or rather to be seen in a different context. It's about an operand's "on the fly conversion" of text to number when doing calculations, not what would be accepted as numeric cell input. The context is https://help.libreoffice.org/6.4/en-US/text/shared/optionen/detailedcalculation.html?&DbPAR=CALC