Huh, interesting ideas. I'll address them in separate posts.
Given that trips are started and stopped by starting and stopping the engine, and the database is kinda keyed from the point of view of trips, it seems like it would be more useful to allow someone to dump specific trips to kml [rather than selecting datums based purely on date]. If you're envisaging selecting trips based on those two date parameters, then feel free to ignore what I'm about to say.
I can think of a couple things that might work:
1) Give a trip list and then let people choose them:
By just doing ranges, you make it easy to sscanf, and the sql WHERE clause is easier to build. [go me, lazy as hell as ever]
$ obd2kml --list-trips
TripID Start End
1 2009-05-06 21:03 2009-05-09 06:12
2 2009-06-01 09:33 2009-06-01 10:45
$ obd2kml --trips=1-2
The other benefits of this is that you don't have to deal with time conversions [except once, for printing to stdout - which is a lot easier than trying to parse stuff and convert to epoch seconds], and that you don't have to worry about timezones.
2) Another option might be to do what you describe, but use the dates to select the trips. You could modify the trip select sql [around line 157 in obdgpskml.c] to be something like:
And you'd get all trips that touch the timeframe you've described.
"SELECT tripid,start,end FROM trip
WHERE (trip.end<%f AND trip.end>%f)
OR (trip.start<%f AND trip.start>%f)
ORDER BY tripid", endtime, starttime, endtime, starttime)
Again, you'd have to parse the dates as input to convert them to epoch seconds. Which sucks to do portably IME, which is why you'll notice my code never attempts to do such a thing.
I'm not sure which of these would be "better" - this is probably one of those times where we can either talk about it, or you can just post a patch and I'll probably accept it. Or you could wait a couple days while my brain percolates the issue and I figure out how I think it would be best done, and I get round to implementing it.