In addition to making new features, I have been fixing bugs related to these new features. There has been a steady trickle of these bugs, some of which have been introduced alongside a new feature, some of which had already existed in an old feature and a couple of which have required upstream fixes in the graph library, Metrics Graphics. One of the latter was quite interesting, so here it is in detail.

One of my colleagues filed a bug about a graph that was displaying some data about the ratio of crashes each day over a couple of weeks. There was a graph and a table that were supposed to be showing the same data, but for some reason they were different. In the table, the ratio of crashes increased dramatically on the 6 August:

But in the graph the spike was on 5 August:

First I tried to reproduce the problem, but when I did, I saw this graph, which agreed with the table:

Strange. How were the graphs were being made? The data came from our Python middleware, with each point on the graph being represented by two numbers: one for the ratio and the other for the date, as a time stamp (in this case an integer representing the number of seconds since 1 January 1970, in UTC time). Our JavaScript then passed this data on to Metrics Graphics, but first it converted the dates into JavaScript Date objects, as required by Metrics Graphics. (The value of a Date object is also a time stamp.) Finally Metrics Graphics was drawing the graph, using the library D3 to convert the ratios and time stamps into the pixel coordinates of each point, and to draw suitable axes.

Our respective graphs were being drawn using the same data, with the dates encoded as the same numbers. So why were they different, and what was so special about me that made the graphs work for me but no-one else?

I’m British, that’s what.

It was a time zone issue. The dates in the table were the dates according to UTC time, as were the JavaScript dates we were handing over to Metrics Graphics. But in order to plot the points and draw the axes, D3 was taking the time stamps and converting them to local time, which in the UK is the same as UTC time. (Actually since it’s summer, the UK time and UTC time differ by 1 hour, but this was not enough to affect the dates here. The times on this particular graph are set to midnight, however, so even my graph was slightly wrong: the points should have been aligned with the ticks on the x-axis.)

The solution was for Metrics Graphics to offer a new option to convert the time stamps in UTC time instead. So now everyone sees this:

Oh, that sounds very interesting! Interesting problem, and interesting problem solving approach!

LikeLike