Download it now!
Bug 118850 - Custom time format changes to default upon load (only those saved from older versions)
Summary: Custom time format changes to default upon load (only those saved from older ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.1.3 release
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:6.2.0 target:6.1.2
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-20 06:46 UTC by stephan.sotter
Modified: 2018-09-06 15:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of bad behavior (196.63 KB, image/png)
2018-09-03 15:17 UTC, stephan.sotter
Details
Example file saved from 5.0.2.2 (8.58 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-09-04 14:07 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stephan.sotter 2018-07-20 06:46:11 UTC
Description:
Certain custom time/number formats get changed to another format upon loading the document. Happens when the document was saved with any version up to 5.0 and opened with any version 5.1 or higher (or vice versa).

Steps to Reproduce:
1. Enter 0,333333 in a cell (any value works, really but there has to be a value)
2. Define this custom format: H:MM;@ for the cell
3. Save the document in any LO 5.0 Version or lower
4. Reopen it with LO 5.1 or higher

Actual Results:
Cells that contain values that have this format applied are changed to standard number format. You can find and reapply the custom format in the list. Afterwards it works fine.
Curiously empty cells are not affected - probably no validity check upon loading?

Expected Results:
Keeping the correct time format for all cells.


Reproducible: Always


User Profile Reset: No



Additional Info:
Doesn't happen with all custom formats; apparently just ones that defy the intended logic of the formatting code rules. In the example H:MM;@ I'm not sure about the intended function of the @ part is. It doesn't seem to change behavior skipping the @. And H:MM as a custom format doesn't show the problematic behavior. But anyway that's what the user entered and thus had his documents misformatted when we changed to LO 5.2.7

Anyway, it's inconsistent when the program functions normally upon entering the number format, but at the same time recognizes it as invalid and from v5.1 on decides to silently "correct the error" when it actually has the capability to apply it correctly.
Comment 1 Xavier Van Wijmeersch 2018-07-20 08:56:18 UTC
this custom format H:MM;@ will chance in a text format
@ ==> text format
In LO 6.2 it shows just the value in text format, but in LO5.0 and higher it will show HH:MM:0.333333

I am not sure if this is a bug, or a misunderstanding of the function @
Comment 2 stephan.sotter 2018-07-23 06:39:36 UTC
Well I'm sure it's both. As I understand it the @ has no (useful) purpose here, so yes it's probably a misunderstanding of the function.

But at the same time the behavior LO shows is not consistent across the version jump 5.0 to 5.1
However wrong something I entered is LO should not accept it in one version, then silently change it in another.
Comment 3 stephan.sotter 2018-07-23 06:41:39 UTC
To clarify: It doesn't just change the way it displays the value, it changes the number format to default.
Comment 4 Buovjaga 2018-09-03 11:15:10 UTC
(In reply to Xavier Van Wijmeersch from comment #1)
> this custom format H:MM;@ will chance in a text format
> @ ==> text format
> In LO 6.2 it shows just the value in text format, but in LO5.0 and higher it
> will show HH:MM:0.333333
> 
> I am not sure if this is a bug, or a misunderstanding of the function @

If I do the steps in 6.2, it stays in Time format. Tried both with Finnish and English (USA).

Stephan: can you test the steps from scratch with 6.2: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Comment 5 stephan.sotter 2018-09-03 15:17:50 UTC
Created attachment 144635 [details]
Screenshot of bad behavior

Same file, created with LO 5.2 portable, opened with LO 6.2 dev
Comment 6 stephan.sotter 2018-09-03 15:20:31 UTC
Sorry, still not fixed. Maybe it's a configuration issue?
The portable version obviously has a different configuration from the installed 6.0 and 6.2 dev I tested against.
Comment 7 Buovjaga 2018-09-03 16:34:48 UTC
(In reply to stephan.sotter from comment #5)
> Created attachment 144635 [details]
> Screenshot of bad behavior
> 
> Same file, created with LO 5.2 portable, opened with LO 6.2 dev

And what if you create it with 6.2?
Comment 8 raal 2018-09-03 20:28:45 UTC
I can reproduce with 4.1-> 6.2,but cannot reproduce in 6.2 (file created with 6.2). Linux.
Bug in older version, now fixed?
Comment 9 stephan.sotter 2018-09-04 05:43:43 UTC
Saving and loading in the same version was never the issue (see original description), the problem is that it breaks documents that were *created with an older version* of LibreOffice (older than 5.1). So for these documents I'm either stuck with 5.0 or have to fix each one of them and save them with a new version.
Comment 10 Buovjaga 2018-09-04 14:07:44 UTC
Created attachment 144670 [details]
Example file saved from 5.0.2.2

1. Input 0,333333
2. Changed formatting to H:MM;@ and cell language to English (USA), which is important

It shows the problem with 6.2
Comment 11 Buovjaga 2018-09-04 14:09:01 UTC
Eike: I created the test case you requested.
Comment 12 Eike Rathke 2018-09-04 19:43:53 UTC
Thanks.

Base of the problem is that the 5.0 version (and earlier?) did not store the cell as time cell, so when loading the explicitly set en-US locale leads to the default number format (of that cell type, i.e. float number) of that locale being applied. Which again with some twisted logic is needed if there is no cell style but a cell type ...

Attached sample stored with 5.0:

          <table:table-cell office:value-type="float" office:value="0.333333" calcext:value-type="float">

Stored with 6.2/master:

          <table:table-cell office:value-type="time" office:time-value="PT07H59M59.9712S" calcext:value-type="time">
Comment 13 Commit Notification 2018-09-05 12:22:51 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ede27cf598ed2aef41b9552b2c787ef8331400fc

Resolves: tdf#118850 disentangle the twisted wrong cell type vs format type

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Eike Rathke 2018-09-05 12:24:43 UTC
Pending review https://gerrit.libreoffice.org/60033 for 6-1
Comment 15 Buovjaga 2018-09-05 18:38:10 UTC
Cheers, verified.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 033a68c49fe2b8aa397832d92d400eb0259ea809
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on September 5th 2018
Comment 16 stephan.sotter 2018-09-06 08:16:22 UTC
Can verify as well that the problem has been solved. Thank you very much!

Tested on
Windows 10 Pro, Version 1703

LibreOffice Version: 6.2.0.0.alpha0+
Build ID: 7f43f0b50135e147fb2bb1f942da3bf60153fd2c
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-09-06_00:12:14
Locale: de-DE (de_DE); Calc: CL
Comment 17 Commit Notification 2018-09-06 15:53:29 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=68817986a428bafc433528c49d99df5b58c7204d&h=libreoffice-6-1

Resolves: tdf#118850 disentangle the twisted wrong cell type vs format type

It will be available in 6.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.