Worst update ever. Whenever I open a document it changes all the formatting in my tables, especially any dates.
Version: 6.4.3.2
Build ID: 1:6.4.3-0ubuntu0.20.04.1
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3;
Locale: en-CA (en_CA.UTF-8); UI-Language: en-US
Calc: threaded
And what is the question really? Uninstall the current build, get a previous one (just browse any server that hosts LibreOffice, example: Index of /pub/tdf/libreoffice/stable/ ) and install.
Thank you for your response. Do I need to uninstall the current version first? Are there any pitfalls I should look out for?
First of all: I don’t know the problems you are talking of.
Are you sure there aren’t problems with your system/install independent of the version?
Was there a crash recently which may have corrupted the user profile e.g?
I upgraded my system from Ubuntu 19 to Ubuntu 20. Everything was working fine before the upgrade. I have been using LibreOffice for some time and OpenOffice before that. I have never had this problem before. It has been a very frustrating experience resetting my preferences and options. For some reason the date format resets to a default YYYY-MM-DD. When I open an existing document all the dates in the table have reformatted. I have to reformat the column to the format I want DD MMMM and even then when I add a new row to the table it has the default date format. I haven’t had a crash but could the user profile have been corrupted during the upgrade process? How would I go about repairing that? My first reaction was to uninstall and install a previous version.
You did not mention you upgraded the operating system. That might have change the locale settings. Check Tools → Options → Language settings → Formats → Locale settings from the LO menu.
Probably Ubuntu changed its opinion about the best default location of LibreOffice (V20 as compared with V19), and did therefore not use the existing profile as it should during an ordinary upgrade of LibO. In this case the downgrading of LibO wouldn’t fix your problem, I’m afraid.
If I guessed correctly: Browse your file system, find your old user profile, and replace the new one with it.
I don’t know the default location of the user profile for any version of Ubuntu, but you may start with the information from LibreOffice user profile - The Document Foundation Wiki.
BTW: What was your previous version of LibO?
Hopefully it isn’t a V3.y. In this case my advice is not applicable!
Thank you both for taking the time to help. I will try your suggestions. And I apologies for my initial bad tempered post, borne entirely out of the frustration of trying to manage my clients accounts on the first of the month.
This is a fairly old post though it was top hit when I searched DuckDuck for information on reverting to an earlier version for a different reason.
In fact the key issue here is still very topical and should be kept alive. It concerns the way LibreOffice links date (and currency and number) formats to the Language and Locale settings. I tried to contribute to this discussion several years ago via bug reports, and the conclusion was that this arrangement is (for reasons not explained) a consequence of the specifications adopted for the odf file format. In that sense, the issue isn’t a bug.
The bug reporting application is not the place to go into detailed discussions, but my conclusion then and now is that the question raised by adrowl indicates that LibreOffice is practically unusable whenever documents have to be passed between countries, even if the language is nominally the same (UK, US, Canada…).
There are one or two other such unfortunate “show-stoppers”; one has to be careful what one says here, but it might be legitimate to speculate on how these apparently irremediable design faults arose and were overlooked, leaving the field without effective competition.
Wow, how wrong!
The locale machinery that LibreOffice uses provides so much flexible ways to create either dynamically adjusting, or fixed, representations, that you may do practically everything with it.
You may use defaults, both in formats, and in locale setting - on document level, or on specific piece - and have the format adjust to fit the receiving party expectations (the default date format in Canada is ISO - they see YYYY-MM-DD; in US they see MM/DD/YY or whatever standard they use by default), and so the user reading the document would not have to read the “foreign” format and “decipher” the data. But if the author thinks that their document should look in a specific way, and be independent of the place where they read it - they apply specific fixed locale to the data. And that makes it completely controllable and usable when passing documents between countries. But any great flexibility comes with a learning curve.
… and that is completely unrelated to the topic of “going back to previous versions”, so discussing it here is complete offtopic: if you think it deserves “keeping alive”, create a dedicated question, and have it link here if you want to establish some context.
This is a very old bug - Bug 46448 - with loads of duplicates. And it’s still running.
It impinges on data integrity so it’s fatal for any document that contains a date (or a number with thousands or decimal separator). Comment 4 indicates (perhaps inadvertently) the risks if you miss a checkbox among the confusing settings. No amount of ranting about locale machinery, learning curves and allegations of drifting OT will fix that.
The point is that these data formats should have nothing to do with the locale or the operating system, one or both of which, at the transmitting or receiving end, might make alterations unbeknown to the party reading a document.
What in
seemed unclear to you?
But well, if someone wanted to rant, you can’t do anything about it.