Newbie can't get sort working in Tags or Private Comments columns

I would like my book list sorted by the numbering schemes in either my Tags column or Private Comments column, but the sort feature is not returning expected results (Books in numerical order). I have tried sorting by clicking column heading and also sorting using the arrow icon. I can't find a bug that addresses this, either. Thank you.

Can you post your expected results and what you're getting instead?
Also what browser you're using?

Your problem is the way you have written your numbers. This is an alphabetical sort, so numbers sort 1, 11, 2... If you put leading zeros in front of the shorter numbers it will work. ie. 0651. Right now it sorts as 6, which comes after 1 in 1001.

Thank you all very much. I put a leading zero(s) in front of the numbers in the tag information so that the numbers were all four characters in length. This worked for that column. I had to do more tweaking on the numbers in the Private Comment column. I had just put a number by itself (i.e. 641) in that column. It wouldn't hold the leading zeros in place when I saved the entry - just deleted them out. I had to put alphabetic characters first before the number to make it work (i.e. "Number 0641"). Again, thanks so much!

>4 KJAdkins: ? What? That sounds like a bug. Could you please describe what happened? And how you input the numbers? (i.e. you can edit the Private Comments from "Edit book" or from "Your books" and possibly in other ways too. But for a bug report, we need to know how to make the bug visible, i.e. precise steps to make it appear).

For what it's worth, I believe another user and I discovered a while back (maybe 3 months ago?) that leading spaces were being deleted in certain fields, which I believe at that time included private comments. Some fields for which this fact was discovered were reverted to allowing leading spaces, but I believe staff at the time decided it was most likely that a leading space in a field like comments or private comments would be a mistake by the user and therefore would get automatically removed (a decision I still disagree with, for the record, because it removed feature availability for those of us who use leading spaces in for our workflow). I wonder if whatever bit of the code removes those leading spaces also removes leading zeros when found.

>6 GraceCollection: I think that was me :-)
And yes, spaces got some special treatment, but I haven't noticed anything with numbers, which is why I tried to replicate the 641 behaviour from >4 KJAdkins: But I don't see the bug (and Private Comment is hidden for all other users, so I can't see what >4 KJAdkins: did, that I didn't do).

ETA: I got it. If you enter 00641 in a previously empty Private Comment (in Edit book) it works as expected. (i.e. the Field contains 00641).
But if you first enter 641 and save it. And then go to "Edit book" again and enters 00641 the bug shows up and the field is still 641.
A workaround is to input A00641 and save. And then 00641 and save.

I think >4 KJAdkins: should open a bug report on this. I don't think it "deletes" the leading zeros. I just think that it checks if the old contents and the new contents are the same number and then doesn't save the new contents if it decides that they are the same.

So to replicate the bug, take any book with an empty Private Comment field.

Private Comment: empty gives Private Comment = ""
Private Comment: 641 gives Private Comment = "641"
Private Comment: 00641 gives Private Comment = "641"
Private Comment: A00641 gives Private Comment = "A00641"
Private Comment: 00641 gives Private Comment = "00641"

And as I suspected:

Private Comment: empty gives Private Comment = ""
Private Comment: 00641 gives Private Comment = "00641"
Private Comment: 641 gives Private Comment = "00641"
Private Comment: A00641 gives Private Comment = "A00641"
Private Comment: 641 gives Private Comment = "641"

I.e. it doesn't delete leading zeros, it just ignores them when saving the contents of the field.

The previous bug report for when this started happening, is at: https://www.librarything.com/topic/373033

The outcome of that report was that staff re-enabled internal spaces in the comments, and private comments fields, but decided to continue stripping the spaces at the start and end of the field (post number 36).

>8 Nevov: But, as bnielsen shows, the leading zeros thing is a different bug

>9 jjwilson61: Yes and the honor for discovering that bug should go to @KJAdkins but maybe we should just mention that and do the bug report? (I have a "golden bug" exterminator medal earned years ago, so I don't need more gun notches :-)

>9 jjwilson61:
Well said, thanks. I somehow blanked that spaces and zeroes are not the same thing!

I've made it into a bug report here:
https://www.librarything.com/topic/374759

As an explanation to the OP:
As discribed at https://wiki.librarything.com/index.php/Helper_badges, members can get badges for some of the work they do to keep LT working and up to date. A lot of what makes LT function is done by Members. Things like filling in Common Knowledge. One of the badges is called 'Exterminator' which is awarded for 'reporting bugs resolved as fixed'. It also has the special feature that when you get 25, you don't get a normal gold badge, but rather a gold bug. It seems to take a long time to collect those 25 points. These bugs are valued by those who have them, and by those trying to get them. In this case the bug is real, and very likely to get fixed quickly.

I should add that the real reward for helping on the site is not the badges, but the better functioning of the site. But the badges are fun, and they encourage people to get used to helping.

This is reported as fixed.

Thank you all very much for your time and efforts to address this bug. I have not used LibraryThing for several days since my last message entry so did not see your responses until now. Again, I appreciate everyone's work in resolving this issue.