Undocumented because I can't find anything that even hints at the possibility that "adding zero will cause truncation" anywhere in BOL or on the web.
Unsupported because Microsoft PSS has explicitly stated that this behavior of DateAdd() is undocumented, unsupported, and unreliable. It is subject to change at their whim, expected to change, and is emphatically not guaranteed to work.
I'll conceed your point on non-standard because there isn't any formal standard for date manipulation in SQL.
I still maintain that conversion to the ISO character form and manipulating that character form is more portable and easier to understand than relying on obscure behaviors of vendor specific functions that even the vendor's own support group gets nervous about!
Are you sure Pat? I don't there is any trickery here. The inner function works out how many hours have passed from "zero" date (and this could also be any genuine date so long as it is also used in the outer equation) to the supplied date. The outer equation then adds that number of hours to the "zero" date. If that isn't supported then I worry about any use of dateadd\ datediff.
Are you sure Pat? I don't there is any trickery here.
The problem lies in treating zero (an integer) as though it were a date. As type checking beomes available in future releases of T-SQL, this behavior is presumed to fail. Although I haven't been privvy to discussions about such things lately, there was also consideration for changing the "zero" date value if the julian to gregorian conversion issues could be settled (to allow references to dates much earlier than the present version of SQL Server allows).
While Rudy's trick works (at least for now), I see it as very poor practice. It relies on being able to subvert type conversion which is problematic, it relies on undocumented behaviors related to that subversion, and it is difficult for new users to understand (at least in my experience).