...
I guess I'll have to retest on that. In multiple different threads, Michael and Peter showed that controlling the order of execution within the formula with parenthesis performed worse but that was a long time ago and could stand a revisit.
...
I was really joking about CPU cycles...
That was done purely for better readability and understanding, as 1900 can be easily recognised as a common SQL Server start year when 22800 looks a bit strange.
Actually, there is another way of having it done:
sometimes, detailed calendar table could be the answer
let say
CALENDAR (Date date, Year int, Month int, Day int, FirstDayOfMonth date, LastDayOfMonth date, ...)
so you can simply query it (eg using CROSS APPLY) as
SELECT FirstDayOfMonth, LastDayOfMonth
FROM CALENDAR
WHERE Year = @Year AND Month = @Month AND Day = 1
For some reason I think that with proper indexes on CALENDAR table the above will give the best performance.
Now, about using strings.
Actually, you will often hear two opinions on this subject:
1. My one
&
2. Wrong one
:hehe:
Seriously, some will still use string conversion as it's easier for them to understand really function does. Another ones, with a bit more knowledge about integer math behind of SQL dates, will be more than happy to use one based in calculations.
It's like using logic based on bit math operations. Some people just do not get it. So they do avoid it.;-)