About an hour ago I gave a presentation on IndexedDB. One of the attendees asked about dates and being able to filter based on a date range. I told him that my assumption was that you would need to convert the dates into numbers and use a number-based range. Turns out I was wrong. Here is an example.
I began by creating an objectstore that used an index on the created field. Since our intent is to search via a date field, I decided "created" would be a good name. I also named my objectstore as "data". Boring, but it works.
Next - I built a simple way to seed data. I based on a button click event to add 10 objects. Each object will have one property, created, and the date object will be based on a random date from now till 7 days in the future.
Note that since IndexedDB calls are asynchronous, my code should handle updating the user to let them know when the operation is done. Since this is just a quick demo though, and since that add operation will complete incredibly fast, I decided to not worry about it.
So at this point we'd have an application that lets us add data containing a created property with a valid JavaScript date. Note I didn't change it to milliseconds. I just passed it in as is.
For the final portion I added two date fields on my page. In Chrome this is rendered nicely:

Based on these, I can then create an IndexedDB range of either bounds, lowerBounds, or upperBounds. I.e., give me crap either after a date, before a date, or inside a date range.
The only conversion required here was to take the user input and turn it into "real" date objects. Once done, everything works great:

You can run the full demo below.
Archived Comments
Why just not use the BETWEEN function in SQL to accomplish the same thing?
Um... you know this is IndexedDB, right? I'm talking about client-side storage of data, not server-side.
Well by golly you are correct. Has been a long day. Been working on a lighted sign at a Hilton all day. Good ole' JavaScript above, if I would pay attention to it. CreateStoreData... Clicking now.
"Has been a long day." It happens. :)
Thanks for the tutorial, here is a question
Why do you store the date as Date Object ?
isn't saving the date as a number (date.getTime()) would be faster ?
and we will still be able to search for a date between two dates ?
am i missing something ?
Um, I don't quite get your question. I stored it as a date object because thats what my data was, and it worked just fine (also allowing for searches). Now - to your question of performance, I don't know if converting it to numbers would be faster or not.
I have noticed that storing date as a key converts it to a string, and generally as far as i know working with numbers is faster than strings (at least it will save storage), so we can store the epoch time (date.getTime()) and use the index bound functions on that number...
any way, this is just a performance thing, thanks again for the tutorial
No problem, and thanks for commenting.