Unupvote + (re)upvote isn't cancelled out for daily reputation cap calculation

Question

I have seen the notice about "Daily rep limit = 200; accepted answer and bounties do not count against this limit" notice for a while. November 17th was the first time I reached that 200 limit (for upvotes) but something didn't seem quit right about the "new math" being used.

My total was 220. Two answers were accepted so that counts for 30 points. If I am not mistaken, 220 - 30 = 190. And yes, there were additional votes that did not get counted towards rep (as opposed to those 19 upvotes being the only 19). Looking at the detailed history, I saw some wackiness with one particular question (Password generator function):

+25 / -10   08:28:01    3 events     Password generator function
     +10    08:28:01    upvote
     -10    08:27:58    unupvote
     +15    08:27:52    accept

So, within 9 seconds there was an "accept", an "unupvote", and then an "upvote", in that order. It seems reasonable to conclude that the O.P., after accepting the answer, clicked on the "upvote" again which cancelled it, and then immediately (3 seconds) added it back. So that upvote shouldn't be counting towards rep earned on November 17th because that rep was really earned in the past. The combination of unupvote + upvote should cancel each other out, right?

Info found in further investigation might shed more light on why the upvote counted on the 17th as "rep earned for the current day". This page showing the details noted above ( https://dba.stackexchange.com/users/30859/srutzky?tab=reputation ) shows a total of 220 points for the day (+230, -10). Yet this page ( https://dba.stackexchange.com/reputation ), which probably only shows your info and not mine, shows -- 2015-11-17 rep +230 = 10853 along with the details of me gaining 10 points from that upvote, but no loss of 10 from the unupvote. Since it doesn't show the -10 for the "unupvote" yet still has the correct amount of rep earned in total, that lead me to think that rather than entering in a "correcting" entry of -10, this view of the data actually removes the original event of +10. And the first screen ("reputation" tab of my profile), since it does show the -10, would still have that original upvote recorded.

I compared both of those views of the data, starting on July 29th (the first entries for that question) and found that the "reputation" tab on my profile shows 2 upvote events on July 30th for that Question and a total of 65 rep points for that day. Yet the "rep stats dump" (or whatever that page is called) only records a single upvote event on July 30th for that Question -- and a total of 55 rep points that day instead of 65 -- shown here:

 2    108500 (10)
 2    108500 (10)
 2    108500 (10)
 2    108442 (10)   <--- the Question in question ;-)
 1    108500 (15)
-- 2015-07-30 rep +55   = 4944   

So the "rep stats dump" view of the world, by removing the original event upon "undoing" the event, causes undoing an accidental "undo" to look like those points are earned on the current day instead of in the past when that event really occurred.

I'm not sure what to recommend here as a change since I am not sure if these two pages are just different queries of the same data, or two separate tables. I can say that whether it is the actual data or just a query showing a particular view of the data, it makes sense enough to remove original events (e.g. an upvote) if a cancelling event (e.g. an unupvote) occurs on the same day, but if the cancelling event is on another day, then the original event should remain and a correcting entry should be added. And in this case, the "correcting entry" added when the unupvote occurred would be removed when the re-upvote occurred, and that one did not get recorded. The end result is that the original entry is the only one that would remain. This makes a lot more sense to me as a way of viewing past rep points and events since it shows what actually happened, whereas the current method of removing the original record alters the past (which I am not a fan of, both in terms of data purity / integrity as well as having a general distaste for historical revisionism).

---

I looked on "meta.DBA" and the main "meta.SE" site but didn't see this particular issue reported before, though I did find these posts on the main "meta" site that seem related:

• Probably a bug in computing user reputation

• Daily reputation cap effectively counts downvotes twice

I could have added a comment or answer or even a question on the main "meta.SE" site, but since I didn't find anything even remotely close to reputation bugs on the "meta.DBA" site, I figured there should be some representation ;-).

And this is clearly not a major issue (I'm sure it's an edge-case), but it seemed like the behavior should still be documented.

Answer 1

This isn't a bug, it's status-bydesign. The unupvote is the confusing piece.

Your rep for Nov 17th shows a -10, but this is actually impacting your rep on the day for the original vote, July 30th. When an unupvote happens, it's like the original vote never happened...poof, it disappeared on July 30 along with the rep, even though the action happened much later.

The recast upvote does count for the day it happened, Nov 17. The total number of upvotes you got for the day was, in fact, 20, meaning you hit the rep cap based on upvotes.

Confused yet? This has been discussed on Meta.SE and there is even a feature-request to make this visually clearer. If you think that'd be helpful go upvote it, and then unupvote it, and then upvote it again to add to confusion.