The order of columns does matter when it comes to indexes. Whether or not it'll matter in your case depends.
Let me explain.
Let's say you have a person table, with first, last, and middle name.
So you create this index, with the columns in the following order:
FirstName, MiddleName, LastName
Now, let's say you now do a query using a WHERE on all of those columns. It'll use the entire index.
But, let's say you only query on first and last name, what happens now is that while it will still use the query, it will grab the range of the index that has the same first name as your WHERE-clause, then scan those, retrieving those that have a matching last name. Note, it will scan all the rows with the same first name.
However, if you had rearranged the index, like this:
FirstName, LastName, MiddleName
Then the above query would grab the range of the index that has the same first and last name, and retrieve those.
It's easier to grasp if you look at it in another way.
The phone book is sorted by last name, then firstname and middle name. If you had put middle name between first and last name, and sorted, then people with the same first and last name would seemingly be all over the place, simply because you sorted on middle name before first name.
Hence, if you're looking for my name, which is "Lasse Vågsæther Karlsen", you'll find all the Karlsen-people, we would be located in a sequential list in the phone book, but my name would be seemingly randomly placed, simply because the list would then be sorted by Vågsæther.
So an index can be used, even if the query doesn't use all the columns in the index, but the quick lookup-features only work as long as the columns are listed at the front of the index. Once you skip a column, some kind of scan takes place.
Now, if all your queries use both id and date, it won't matter much, but if all the queries include date, and only some of them contain an id, then I'd put date first, and id second, this way the index would be used in more cases.