The perils of DATEDIFF

I just ran into a problem with a stored procedure that updated a table. We received the following error:

The datediff function resulted in an overflow. The number of dateparts separating two date/time instances is too large. Try to use datediff with a less precise datepart.

Looking in the stored procedure I found this:

IF (DATEDIFF(ms, @LastModifiedAtLoad, @currentLastModified) >= 200)

This is comparing two dates down to the millisecond. I looked at the documentation for DATEDIFF on MSDN and rapidly found this:

If the return value is out of range for int (-2,147,483,648 to +2,147,483,647), an error is returned. For millisecond, the maximum difference between startdate and enddate is 24 days, 20 hours, 31 minutes and 23.647 seconds. For second, the maximum difference is 68 years.

So, it should have been:

IF (DATEDIFF(s, @LastModifiedAtLoad, @currentLastModified) >= 200)

This stored procedure was doing the wrong kind of comparison. It should have just done this:

IF (@LastModifiedAtLoad > @currentLastModified)

This works for all non null dates, not just those that are close enough together to compare.