Haha. I know very well that banks aren’t interested in providing customer service but that is the missing field.
You might find the Calc guide a useful reference, download from English documentation | LibreOffice Documentation - LibreOffice User Guides . I still find there is new stuff to learn as more functionality is added over time
I meditated on this a bit … So Excel must then assume that before sorting, the data was in some order (descending, presumably?). Why? Possibly that requires analyzing the data first … and then, if it fits the “descending” pattern, reverse the order also for elements that compare equal … would likely be slower? or maybe not - maybe this check could be combined into the quicksort somehow? No idea. If it can be implemented without much of a sacrifice, it could be a reasonable “make it smarter” enhancement request … @erAck what is your take?
I would be careful with “logical” sort without the user’s knowledge or consent. If I am not mistaken, the rule today is to sort the values in the order defined by the user and in case of exact same value, to keep them in the order of the original list. If this behavior is modified because the sort routine “detects” that it is a bank statement and revert the order, then we break the consistency of the sort routine. Also, my bank first lists the debits, then the credits for same day transactions. Again, as mentioned previously, the issue is the presence of the balance on each line which makes the lines dependent of each others.
.
For me, the only additional valid option is “revert the order of the lines”.
I would agree … except the current “stable sort” convention is also a convention, used without the user’s knowledge or consent (and surprising users other than those who happen to be OK with it).
But a “revert order” operation of course is another valid option, usable when the user knows that the order is correct (which should likely be true in cases where the discussed issue arises).
I am not saying that the development team should do anything to the existing software other than be aware that an issue can arise and perhaps think of possible ways it could be resolved. I am sure they will be far more aware of the consequences of making any changes than I am.
This rule applies to both Excel and Calc.
The result of sorting a range of cells from Sample File.ods file in ascending order of Transaction Date values is the same for Excel and Calc.
Persistent stable sort for already sorted data is expected especially in a subsequent sort on a second column. Switching from ascending to descending sort or vice versa on the same column there is no logical reason to reverse equal entries. I’d rather offer a Reverse “sort” on a single column, additionally to Ascending and Descending.
But yes, the original reason for this request here is bad data with date but without time nor sequential IDs.
For me,
Microsoft® Excel® para Microsoft 365 MSO (versión 2312 compilación 16.0.17126.20126) de 64 bits
sorts in the very same order than LibreOffice.
Actually, no they haven’t, LibreOffice is, without a doubt, one of the worst file types I have ever come across in my 30 year book-keeping career! Try sorting calendar dates, for example. Excel manages, but LibreOffice falls flat on its face every time. Unfortunately, my office thinks that LibreOffice is the"bees knees" and I’m outvoted!
If your dates are actually date values and not just text strings in some ugly date “convention” like “month/day/year” or even worse, then they sort perfectly fine. In both Excel and LibreOffice Calc.
The notion of asking ANY bank to change their output is hilarious! What are people thinking? The fact that people would make suggestions like this is a symptom of something seriously wrong in the Open/LibreOffice back-end. Actually, the problems of this type in Open/LibreOffice are the result of an extremely old foundation. The innards haven’t changed since it first appeared as StarOffice about 30 years ago, regardless of the spiffy-looking appearance. Many Askers sign off with “Maybe a change will happen with the next release . . .” Well, listen up, sports fans: the innards never change; they’re as primitive and clumsy as they were 30 years ago. Look at the calendar tools: selecting “Canada” still produces a Hebrew calendar! Open/LibreOffice has never heard of ISO8601 calendar dates which have been standard in data-processing since 1988! And importing csv files still asks about “special numbers”, a concept useful only to drug-addicted wierdos with OCD. In 2024 it’s not unreasonable to expect a data tool like Calc to be able to import a CSV text file into an SQL or DBF format in one click. Is anybody in the Calc department even listening?!
No it doesn’t. Look what OO/LO does when trying to change calendar dates format (theoretically a trivial change). It works up to the 12th day of the month when it decides that “days” are now “months”, and then the output morphs:
This behavior has been unchanged for at least 25 years, possibly since Oracle fired all the original developers and donated the source to charity.
PLEASE STOP TELLING BULLSHIT …especially when you can’t even spot the difference between “Canada” and “Kannada”!
(Kannada - Wikipedia)
I agree with you that asking a bank to change anything is hilarious. Personally I know two people who worked for major banks, who were tasked by senior staff at the bank to make changes to their system only to find that the same senior staff blocked any changes being made. In both cases they left and found work where they could actually be productive. If you think the innards of Libre/Open Office are old I suspect, but don’t know for sure, that the back office processing in banks is still using 60’s programs written in Cobol running on IBM/ICL mainframe emulators. They daren’t touch it because there are no longer any Cobol programmers around and so they have no idea how it works.
I disagree about the idea that Calc should be able to import a .csv file and correctly assign all variables with a single click. Everything in a .csv file is stored as plain text. Calc has a number of special character types so how is it supposed to know which special character type to assign to each variable. It gives you the option to tell it what variables are. If you ignore that choice it will import everything as plain text and then a date column will not sort correctly. If, however, you tell it that a column contains dates then Calc converts the plain text to date format correctly and it will then sort correctly.
Well I have obviously no idea how you got to that state. My bank exports data in .csv format with what are supposed to be dates in the first column. When I open that with Calc it gives me a panel where I can change whatever defaults it has selected. The top of each column defaults to “Standard”. If I don’t alter anything it treats everything as text and the first column does not behave like normal dates. If, however, I change the selection at the top of the first column to one of the date formats, in my case D/M/Y, then it behaves perfectly correctly.
Karolus, I’m thinking you’re perhaps becoming a bit deranged, that you might not know about Hebrew calendars? This is what you get in LibreOffice when you select Canada as region:
Correct me if I’m wrong, but these sure look like Hebrew calendar dates, my friend.
It seems youre the ONE who’s deranged:
From your screenshot I dont see Canada … but I see English(USA) where it makes perfectly sense to provide …(additional to the stupid US-Format M/D/Y)… also jewish Calendars for jewish citizens!
btw. I’m not your friend!
As you might clearly see that is not English (Canada) but English (USA), which has formats of two calendars defined.
There you are. A mixture of date values and text strings. If that is the result of an import of a CSV file then in the import dialog set the first column to type Date of order DMY (or maybe switch the import locale to en-GB / English (UK)), otherwise if you are working or importing in an en-US locale only MDY dates are recognized as such and 13/01/2023 is not a valid M/D/Y date.
To post-process such erroneous import see this FAQ.
… behave. Thanks.
