Quoting @JamesBurke:
I have to assume that this question is going nowhere, and I thank everyone who tried to help. MS Excel can handle the format issues, and LibreOffice can’t, so I’m just going to switch to Excel because I still have to get my work done at the end of the day. Many thanks, everybody!
The question would clearly have a working answer if there were consistent data (dates) Having to regard (among others) the three examples posted with the question
(1.) 08/13/2019 14:43:13 PST Completed USD 68.21 -2.28 65.93
(2.) 21/03/2019 11:03:24 PDT Completed USD 83.74 -2.73 81.01
(3.) 05/04/2019 12:35:13 PDT Completed USD 30.00 -1.41 28.59
we needed to point out that neither a human brain nor a spreadsheet software can reliably make valid data from this without having access to additional information.
Trying to reading the first column as dates we find:
- In he first row that cannot be a date in the (bad) format used in many countries, typically in the UK, because there is no 13th month.
- The second row cannot be a date in the (very bad) format usd in the USA and (ooficially) next to nowhere else, because there is no 21th month.
- the third row gives no clue whether a UK or a USA format should be assumed.
If Excel actually conceals these facts, and returns something without any hinting to the ambiguities, you cannot get your work reliably done by it.
This is not Excel-bashing! To the contrary I precisely showed in the example attached to my second comment on the question that also LibO V7 treated the data in an unacceptable way in one of the demonstarted cases.
You thanked “everyone”, but you didn’t do what was actually necessary when taking part in a kind of forum: You didn’t resolve the contradictions and/or ambiguities and/or typos…
You didn’t even point out which one of the thinkable formats you actually expected to be applied with your examples.
I therefore cannot accept the thanks.
(I also sometimes have something to be done at the end of the day - and at tghe end of of my days, too.)