SQL Server date calculations in stored procedures - sql-server

Question

I wanted to ask 3 questions about below code (please excuse the long code listing, I am including these lines in the hopes that it provides enough context).
Note that the code here depends on the date when it is executed. For this reason my questions refer to a hypothetical situation with two different execution dates:
March 1st 2014
January 1st 2014
My questions are on whether my understanding on some parts of this is correct, i.e:
A. that the SELECT DATEADD expression (on line 1) would:
On March 1st 2014 create the datetime 2014-02-31 23:59:59
B. that the code on lines 6-9 would:
On March 1st 2014 create the datetime 2014-02-01 00:00:00
On January 1st 2014 create the datetime 2013-02-01 00:00:00
and
C. that the code on lines 11-14 would:
On March 1st 2014 create the datetime 2015-01-30 00:00:00
On January 1st 2014 create the datetime 2014-01-30 00:00:00
Is this understanding correct?
1. SET #ldpmth = (SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE()),0)) )
2. SET #yr = (SELECT YEAR(#ldpmth))
3. SET #mth = 0
4. SET #dy = 0
5.
6. SET #fysdate = (SELECT CASE WHEN MONTH(#ldpmth) >= 2 THEN
7. DATEADD(MM, 1,CAST(CAST(#yr+#mth+#dy AS NVARCHAR(50)) AS DATETIME))
8. ELSE DATEADD(MM, 1, CAST(CAST((#yr-1)+#mth+#dy AS NVARCHAR(50))
9. AS DATETIME)) END )
10.
11. SET #fyedate = (SELECT CASE WHEN MONTH(#ldpmth) >= 2 THEN
12. DATEADD(YY, 1, CAST(CAST(#yr+#mth+#dy AS NVARCHAR(50)) AS DATETIME)) + 30
13. ELSE DATEADD(YY, 1, CAST(CAST((#yr-1)+#mth+#dy AS NVARCHAR(50))
14. AS DATETIME)) + 30 END )
(Thank you for all who answered so far. This is actually code that was developed (but not documented) at my place of employment some years ago and I have been tasked with converting it to a form that works client-side with Crystal Reports.)

Answer 1

On March 1st 2014 create the datetime 2014-02-31 23:59:59
No. AFAIK, there isn't any dbms that's so dumb it thinks Feb 31 is an actual date. The SQL statement on line 1 will return the value 'Feb 28 2014 23:59:59'.
You can test all your statements by substituting actual dates for GETDATE() and guesswork. In the first query, for example, use
SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,'2014-03-01'),0));
^^^^^^^^^^
You can probably run a version of SQL Server locally. SQL Server 2008 even installs on Windows XP. If you can't bear that, though, there's always sqlfiddle.com.

Answer 2

This could be easily tested in SQL Server Management Studio (SSMS). I'll answer the first, and you can test the next two yourself.
Question:
A. that the DATEADD (on line 1) would on March 1st 2014 create the datetime 2014-02-31 23:59:59
Answer: No, because February can't possibly have 31 days, so it can't return '2014-02-31`
Proof:
select DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,'2014-03-01'),0))
Results
(No column name)
2014-02-28 23:59:59.000

Answer 3

For (B) and (C), if you'd stated your question, instead, as "My financial years run from 1st February until 30th(sic) January - how do I get the start and end dates for the current financial year, I'd have offered:
SET #fysdate = DATEADD(year,DATEDIFF(month,'19000201',GETDATE())/12,'19000201')
and:
SET #fyedate = DATEADD(year,DATEDIFF(month,'19000201',GETDATE())/12,'19010131')
(Note that this second finds the 31st Jan, not the 30th. I assume that was carelessness in your original question).
But, as to (A), as I indicated, I thought your question is again poorly phrased - if you're trying to find the end point of a period and that period is defined on datetimes (as opposed to just dates), it's far easier to construct an exclusive upper bound:
SET #ldpmth = DATEADD(month, DATEDIFF(month,0,GETDATE()),0)
This bound (to be used with a < comparison rather than <= or BETWEEN) doesn't artificially exclude any values with a time such as 23:59:59.527. Note also, that if the financial year end date calculation is going to be used against datetime values which include times, I'd again counsel computing an exclusive upper bound, and substitute 19010201 instead of 19010131.
So, in total, I don't think I've actually answered your questions as posed, but I think I've provided the answers you should have been seeking.