To gain a bit of a speed increase, you could convert the dates to integer values, as an offset from some base date that all other dates will be after. Choose something like january 1, 1800, or whatever base date is appropriate to your application. The conversion to an offset can be handled by the Date::Calc function Delta_Days(), getting the delta days from the base date to the desired date. Then all of your comparisons can go a little quicker, being integer comparisons, vs date comparisons or whatever.
Kind of an illegitimate cousin of the schwartzian transformation.
I use the most powerful debugger available: print!
This probably won't work as you expect. While it is definitly true interger indexes are always faster than strings, I imagine it would auctually slow things down as it applies to dates. This depends on his SQL engine though. If your using postgres your going to want to see ago for instance. SQL engines normally take dates in numerous string formats, output dates in numerous formats, and store them internally in what ever way is the most optimized - which is surely not string format.
8.5.1.4. Intervals
interval values can be written with the following syntax:
@ quantity unit quantity unit... direction
Where: quantity is a number (possibly signed); unit is second, minute, hour, day, week, month, year, decade, century, millennium, or abbreviations or plurals of these units; direction can be ago or empty. The at sign (@) is optional noise. The amounts of different units are implicitly added up with appropriate sign accounting.
Quantities of days, hours, minutes, and seconds can be specified without explicit unit markings. For example, '1 12:59:10' is read the same as '1 day 12 hours 59 min 10 sec'.
The optional precision p should be between 0 and 6, and defaults to the precision of the input literal.