Created attachment 150271 [details] Table with custom date format Hi, Attached ODS file is (or we need it to be..) created with specific date format DD.MM.YYYY. If it is opened and then saved on machine with local in different format then it is ok, but if saved on machine with same local, then custom data is just lost from saved file.. Same goes for numbers. Is there any way to solve this?
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Hi, I installed version 6.2.3.2 and checked on it, and same problem remain. Attached are example files. So, .odt file is as it should look like (date/number format in our app). Files .ods are converted using macro that say LO to save it as .xls. Ones with sufix _EN are generated when regional settings set as United States, and with sufix _SL when set as Slovenia. So, we have native interface to generate ODT/ODS, so sent files are exact match. Also in our app I can generate reports in different formats, XLS is generated as explained, and there problem starts. Hope this helps.. Regards, Nikola.
Created attachment 151293 [details] native odt
Created attachment 151294 [details] native ods en
Created attachment 151295 [details] native ods sl
Created attachment 151296 [details] xls en
Created attachment 151297 [details] xls sl
I don't understand the problem. The last 4 attachments all look identical. Also, I saved the first attachment as XLS and it looks exactly the same as the original. Please describe the problem *exactly*: - what is the bad result? - in which cell can we see the badness? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information. Arch Linux 64-bit Version: 6.4.0.0.alpha0+ Build ID: b9a776837462eeb6d50d0decc42604c0c3008eb1 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 11 August 2019
Hi, I do not see how is it not explained.. non the less.. picture attached..
Created attachment 153493 [details] picture of bad format
(In reply to Nikola from comment #10) > Created attachment 153493 [details] > picture of bad format Thanks. For me, the dates are displayed as 08.01.19 In all the files. On both Linux and Win 10 Version: 6.4.0.0.alpha0+ (x64) Build ID: 3e64065612acec2eb29aa21e2b515953422256d7 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
Hi, It should only mean that local settings is set the same, as explained in the first place. And it is main problem.. If I have specific date format set, and on local PC I use the same, then it is ignored in converted file. So, if I set specific format then I want to use it, dates, numbers..
(In reply to Nikola from comment #12) > Hi, > > It should only mean that local settings is set the same, as explained in the > first place. And it is main problem.. If I have specific date format set, > and on local PC I use the same, then it is ignored in converted file. So, if > I set specific format then I want to use it, dates, numbers.. So the locale of my operating system should be what in order to see the problem?
(In reply to Buovjaga from comment #13) > (In reply to Nikola from comment #12) > > Hi, > > > > It should only mean that local settings is set the same, as explained in the > > first place. And it is main problem.. If I have specific date format set, > > and on local PC I use the same, then it is ignored in converted file. So, if > > I set specific format then I want to use it, dates, numbers.. > > So the locale of my operating system should be what in order to see the > problem? Setting to NEEDINFO until the info is provided by Nikola
The local should be anything else but the same as described in example, may be m-d-y. So point of this bug report is that custom format is stripped if same used as local for PC.
Hello Nikola, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Hi, As far I see all formats/styles are now stored, so problem looks solved.
Great, let's close