A clustered index must be unique, so if you do decide to go with DATE, you'll need another column(s) which together would always be unique. A clustered index also controls the order of the data physically, so the key should be one that's in ever ascending order. Again, something that your DATE seems to have, which you got right.
However, it would be good to know how much data your table is going to have, and how many nonclustered indexes you plan on using? Since every nonclustered index leaf record includes a pointer to the clustered index, you don't generally speaking want your clustered index to be any larger than it has to be.
Basically the advantages of a simple autointeger number as the key column for a clustered index are that it's effective storage-wise, it always increases in order, and it has good synergy with other objects and use cases as well.
marc_s, a user here, posted a link to another site (link), I think you should definitely check it out.
But to summarize, a clear majority of the time the safe bet is to keep this simple and just put a clustered index on your basic int / bigint identity column, then use nonclustered indexes to optimize searches on specific columns in the table. This is more than good enough for most of the time. No need to complicate things and look for 5% improvement on queries already running more than fast enough. So, the question is, is there any reason for you to expect a standard solution would not work in your case? Like, a huge amount of data (talking bigint scale rows here, exceeding several billions for instance), other performance implications (complex conditional joins to other tables in the same db), or other things like that?