# Reputation for graph is off by a day

So when we view reputation, there is graph view. However, it seems to be off by a day. Here's what I mean:

I'm sure 70 + 20 + 15 is not 15. Its 105, which is what we see below:

And 40 + 10 is NOT 105, unless you did this :)

Anyways 40 + 10 is 50:

So yeah. Did you do what that post on codegolf says? Devs better fix that :)

• Sorry Anna for using your profile... – Universal Electricity Jun 29 '15 at 13:02
• maybe related: meta.stackoverflow.com/questions/296743/… – CRABOLO Jun 29 '15 at 13:02
• You've... hijacked my bug report, mind reader :D – nicael Jun 29 '15 at 13:03
• @Tim Why did you edit the screenshots? I can't tell what profile we're talking about now or what's going on. – Adam Lear Jun 29 '15 at 15:12
• @AnnaLear any plan on this? – Thomas Ayoub Nov 4 '15 at 16:03
• Is this still happening for anyone? We resolved this but didn't find this dupe to close back at the time. If there's still an issue I'll look again but AFAIK this is resolved. It was a JavaScript (possibly-not) UTC date vs. server date issue previously. Also made it fun for our GMT guys to track down... – Nick Craver Nov 11 '15 at 11:12
• @NickCraver I don't think so. – Universal Electricity Nov 12 '15 at 2:28
• Still present as of today, on SO and SU. I'm in Germany (GMT +1), local time is 11:35. – Fabio Turati Dec 3 '15 at 10:35
• In case someone is looking for a way to see today's reputation: way around would be not using bugged graph tab, but to see reputation changes via post or time tabs. – Pshemo Dec 26 '15 at 16:58
• After a year of being reported, this bug is still there. – Sebastian Simon Jul 5 '16 at 20:10
• @Nick yes it still happens, see this recent report. (and comments above) – Shadow Jul 6 '16 at 7:52
• I've updated the code as Ilmari recommended in his answer. – Oded Jul 13 '16 at 14:35

So, I finally decided to dig into the code and see what's causing this. It turns out to be a one-line bug in the StackExchange.user.initRepGraphs() function.

Specifically, at the top of this function, there's a loop that tries to "massage the data into a format that highcharts will like". One part of this is converting a (year / month / day) tuple into milliseconds since January 1, 1970, 00:00:00, UTC. (It does need to be UTC, since the subsequent date formatting code expects UTC, as does the Ajax back-end that returns the rep change events.)

Unfortunately, the code does this incorrectly, by calling new Date(...).getTime() instead of Date.UTC(...). The difference between these two methods is that new Date(...) assumes the input date/time values to be in local time, rather than UTC, and so the resulting timestamps will be offset from midnight by the user's local time zone offset.

This bug doesn't have any visible effects for users in time zones west of UTC (such as the U.S.), since their timestamps will just be some hours later than they should be, and they'll get silently rounded down to midnight anyway. But for us poor folks living in mainland Europe or Asia (or Africa or Australia, etc.), the timestamps will be some hours early, and will therefore fall on the previous day.

Anyway, here's a patch (unified context diff) against the internal 01_rep-graph.js file, as extracted from the user.en.js file linked above:

--- 01_rep-graph.orig.js    2016-01-09 20:07:12.706406358 +0200
+++ 01_rep-graph.edit.js    2016-01-09 20:08:27.871033685 +0200
@@ -15,7 +15,7 @@
var d = rawData[i];

// Date.UTC(year, month, day), where month is 0-11.. INSANITY!
-            var date = new Date(d[0], d[1] - 1, d[2]).getTime(),
+            var date = Date.UTC(d[0], d[1] - 1, d[2]),
realRep = d[3],
rep = Math.max(realRep, -50); // cap the negative bar at -50


Note that, curiously, the comment just before the broken line mentions the correct Date.UTC() method. Perhaps this code used to be correct, until some well-intentioned editor broke it?

Anyway, could someone at SE please apply this patch?

Ps. I've also developed a partial JS hotfix for this bug:

$.ajaxPrefilter( function( options ) { var re = /^(\/ajax\/users\/\d+\/rep\/day\/)(\d+)([\/?#].*)?$/;
var m = re.exec( options.url );
if (!m) return;
var t = 1*m[2], day = 24*60*60, offset = t % day;
if (2*offset > day) offset -= day;
options.url = m[1] + (t - offset) + m[3];
} );


Running this code in the browser JS console should make clicking the rep graph load the rep events for the correct day. The code fixes the Ajax requests for rep events by rounding the timestamp to the nearest midnight UTC, rather than down to the previous midnight as the server effectively does. Alas, it still won't fix the incorrect dates in the tooltips.

This hotfix will be part of the next SOUP release, unless the bug is fixed by SE in the mean time, of course. Impatient folks can already grab it from the SOUP development branch.

It probably is the longest surviving bug in my Stack Exchange history :P. It has already passed its 3rd monthaversary. Though Oded marks the bug as resolved on June 12, this bug is still alive when we're currently in the revision: rev 2015.9.18.3703.

• It's fixed, rah, rah. – cat Jul 13 '16 at 14:58