Grr.. I did a big reply and just lost it.

Yes SQL Server organises the rows inside the data pages in physical order, and with no BOL info to the contrary can assume that the data pages are not in physical order. In that case it would not matter if the clustered index was ASC or DESC.

IF you are adding rows outside the existing date range, then SQL Server would tack them on the end / start of the existing data pages till they are full, and just add a new data page as needed.

The performance hit would come when you whack dates in the middle. When an index data page becomes full, SQL Server splits the page, moving 50% of the data to the new page, adding another Intermediate Level data page. This is also where fragmentation begins. So during your INSERT/UPDATE there is the increased hit of the page split. But then subsequent SELECTs using the index have deeper index pages to dig through. A index reorganise or drop/create would see SQL Server put all the index pages as one level deep, but this isn't something that you would want to be doing all the time.

SQL Server doesn't seem to support bi-directional indexes, but I imagine it would be as efficient in searching forward or backwards though indexes.

Do you agree?