bug: personal records not ranked by time but by date

This is not a bug, it is expected and correct behavior. Since in real life you cannot create a new PR by a worse performance than your last PR, the listing of PRs by date is logical and correct. It looks like you added some of the records manually, hence creating havoc in the PR table. If the 6th PR of 4:45,1 from 2022 is right, then the subsequent performances (the first 6 ones) are no records at all, and you should delete them to keep the table correct.

So the only complain you could have, is why the system allows you to add a better PR manually in the past, when all subsequent PRs are worse, or why it does not delete all later PRs that are worse than the old PR, but I guess people would complain with such functionality even more. In this way you can decide yourself whether you want to keep the incorrect PRs or not.

trux said:

This is not a bug, it is expected and correct behavior.

I would tend to agree (based on the rest of your comments/observations) except that the Rank column exists and shows incorrect information in this case. 

Your argument also rests on the assumption that some of the PRs (perhaps 6 and 7) were retroactively added to the table.

I think another possibility is that flocsy obtained a new watch between PR 6 and PR 5, and that this allowed him to accept a slower 1 KM PR than what already existed.

After all, people often complain that when they get a new watch, it continuously informs them of PRs no matter how fast they go, and the solution that's offered by a Garmin support article and other posters (including myself) is to accept the new PR in Connect so that the watch stops doing this.

It's never happened to me, but I don't think it's out of the realm of possibility that the above situation could lead to a slower "PR" being accepted in Connect for a given distance.

That's just my guess anyway. 

When you get a new watch (or when you factory reset yours), you can (and you should) send your PRs to the watch, in order that it can detect new records correctly. Sure, it would make sense if it happened automatically, but the option is available.

That is good advice, but not entirely relevant to the point I was trying to make.

I was trying to say that there is another explanation for why flocsy's PRs suddenly seemed to "reset" some time between PR 6 (May 19 2022) and PR 5 (Jul 29 2024), other than your assumption that some PRs were retroactively added manually.

trux said:

you can (and you should)

Again I will agree with you in principle, except when you say "should", I think the onus really should fall on Garmin to do this automatically (as you mentioned).

I have seen so many complaints about the "continuous PR" thing from users over the years, and Garmin has obviously noticed it's an issue since they went to the trouble of putting a note in the support article about PRs that you need to manually accept PRs in Connect to get the watch to stop nagging you.

If there's an issue with a poor PR-related user experience that's so widespread that people are constantly complaining about it, and Garmin *could* fix it by automatically syncing old PRs to new devices, then they *should* do so.

Besides, my understanding is the same issue could happens with a brand new watch on a new account (with no existing history / PRs).

A larger question is why Garmin PRs work this way in the first place. There should be no need to manually accept PRs (as advised in the Garmin support article) or to manually send old PRs to a new device (as you suggested). Everything should just work. At the very least, there should be no need for a device to constantly nag the user about "fake" PRs, and there should be no way for a new device to "accidentally" sync PRs that aren't really PRs (if in fact that's what really happened).

All of this is very on-brand for Garmin though. Something that should be very simple is in fact needlessly complex and requires seemingly unnecessary manual intervention.

Regardless whether the higher PR was added manually, or whether the new records were auto-detected because the PR table was not synced to a new device, or the device was factory reset, as long as the fastest time is correct, the newer records are no PRs at all, and as such can be easily deleted to get the table right, so no big deal.

And although the PR sync could happen automatically, I can imagine situations where people would not want it. Some people simply want to start anew up and then. If the sync were automatic, it would be much more complicated to fix the missed PRs manually. So keeping the PR table sync optional is not such a bad solution, after all.

All these explanations are nice, when a developer explains them to a product manager. But irrelevant to the end user. The real fix would be simple: they need to change the order by clause to be rank asc, date asc instead of whatever it is now.

A more complicated , and in my opinion not as good solution would be to add a header above the manually added rows

And the answer from Garmin gives hope:

We were made aware of this issue and are working to resolve this. There is no ETA for a fix at this time but we are actively working on this issue with the Personal Records ranking. We appreciate your patience as we work to get this fixed!

I think both options are relevant. I can understand that you can't set a slower PR than you already have, so the current display is definitely logical, even if it's not what most users are expecting to see. A "top 10 fastest runs" feature would be nice.