So, after working with GadgetCanyon on this for a while it turns out to be a deceptively complex project.
I originally said I'd do it because at first glance it seemed like a simple 10-minute project, and on a PC recording continuously, it would be. However after asking a few questions about usage, the complexity became evident.
If this were continuous data capture on a PC, it would be pretty much dead simple. You have a stream of data being logged every 10 seconds, and after 24 hours of logging (8640 records), you can start to index a pointer that always points 24 hours behind in time and you can read the data at that point in the stream and compare it to the current reading. The memory usage on a modern PC would be trivial. In and done in 15 minutes!
But this is an Arduino and we can't keep 24k of data in RAM and the file manipulation libraries are not as fully-implemented as we'd like. The easy way to do this would be to follow the concept above: keep a pointer in the SD card data and index it forward as needed. Even on a PC this is a bit tricky when working with files, as opposed to memory streams. Due to how the FILE* methods work, I ended up having to open the file in write mode, save the data, close the file and then re-open it in read mode. This was because of limitations on how the seek() and related API calls work.
Even so, this doesn't meet all the requirements. One of the problems is that the logger can be turned on and off at some times, so you're not guaranteed that between now and 24 hours ago, you would have 8,640 records. Therefore the only thing that will work properly, without changing the logging time to use Unix epoch time, or getting involved in complex calculations involving leap years (what happens if yesterday was February 29?), is searching through the data. Easiest is searching from the beginning, but the time becomes O(n) as the file grows. So ideally, we want to search backwards in time, since the maximum search distance is bounded regardless of file length.
I should probably have done that, since in retrospect it would have been simpler, but hindsight and all that...
@GadgetCanyon: As I mentioned, I wasn't able to test it as much as I'd like, so let me know if you have any issues integrating the code I sent into your main sketch.