Yep that works, in fact that's what I've been doing. I was hoping there was a more efficient way to check instead of having to cast to a string and back to a date again. It's not in your example but I cast back to a datetime to do the compare. Not sure if I have to or not.
Do you know how costly casting data in SQL server is?
Pay for processors...pay for memory...make sure they pay you good too!
Seriously, casting/converting datetime and string values is probably not a fast process, but for the string lengths you are dealing with it should not have a big impact on performance. And there is no way around it. MS Access, MS Excel, and other Microsquash products allow you to take the integer portion of the datetime value (a vast operation), but SQL Server uses a different logic for storing datetime values and this method won't work.