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.
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 @
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.
To clarify: It doesn't just change the way it displays the value, it changes the number format to default.
(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/
Created attachment 144635 [details] Screenshot of bad behavior Same file, created with LO 5.2 portable, opened with LO 6.2 dev
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.
(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?
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?
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.
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
Eike: I created the test case you requested.
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">
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.
Pending review https://gerrit.libreoffice.org/60033 for 6-1
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
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
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.