My company made a machine for medical labs, and I wrote an app that monitored the performance of those machines. Our basic metric was samples analyzed per hour, and my app would grab the runlogs from all the machines (we needed the data in the logs for other purposes, or I'd have done the analysis on the machines and just transferred the results), count how many samples were analyzed each calendar day, and then divide by 24. Easy, simple, and worked a treat. That is, until one fine spring Monday.
The service manager walked into my office bearing the graph of machine performance, and said there was something wrong with my script. He showed me the graph, and pointed out that most of the machines had exhibited a nearly 5% drop in productivity on Sunday. This wasn't usual; the machines either worked, or they didn't, and they were expensive enough that labs generally ran them continuously. We looked at the graph for a while, and realized that the affected machines were all in the US; the ones in Asia looked normal.
This was baffling, but I did a little checking of the data, and it looked like the script was counting samples correctly. The nearly 5% drop was real.
But the next day everything was back to normal and people stopped bugging me about this, so I just let it go, though I couldn't get rid of a nagging feeling that I was missing something.
I didn't realize what it was until six months later, when those selfsame machines exhibited a nearly 5% rise in productivity, again reported to me by the service manager on a Monday. I looked at him for a moment, then said, "Not all days are 24 hours long!" I'd forgotten about daylight savings time (not observed in Asia), which makes one day in the spring only 23 hours long, and one day in the fall 25 hours long.
I fixed the calculation by using time()s, so the script'll work for any time zone. As an added bonus, even the occasional leap second is handled correctly.
The service manager walked into my office bearing the graph of machine performance, and said there was something wrong with my script. He showed me the graph, and pointed out that most of the machines had exhibited a nearly 5% drop in productivity on Sunday. This wasn't usual; the machines either worked, or they didn't, and they were expensive enough that labs generally ran them continuously. We looked at the graph for a while, and realized that the affected machines were all in the US; the ones in Asia looked normal.
This was baffling, but I did a little checking of the data, and it looked like the script was counting samples correctly. The nearly 5% drop was real.
But the next day everything was back to normal and people stopped bugging me about this, so I just let it go, though I couldn't get rid of a nagging feeling that I was missing something.
I didn't realize what it was until six months later, when those selfsame machines exhibited a nearly 5% rise in productivity, again reported to me by the service manager on a Monday. I looked at him for a moment, then said, "Not all days are 24 hours long!" I'd forgotten about daylight savings time (not observed in Asia), which makes one day in the spring only 23 hours long, and one day in the fall 25 hours long.
I fixed the calculation by using time()s, so the script'll work for any time zone. As an added bonus, even the occasional leap second is handled correctly.