Re: Passing DateDiff rather than Actual Dates as Parameters
- From: Erland Sommarskog <esquel@xxxxxxxxxxxxx>
- Date: Wed, 30 Nov 2005 09:56:26 +0000 (UTC)
laurenq uantrell (laurenquantrell@xxxxxxxxxxx) writes:
> I've gotten sort of fed up with dealing with regional date settings on
> the client side and am considering the following scheme - just
> wondering if anyone has a negative view of it or not:
>
> Instead of
>
> @StartDate datetime,
> @EndDate datetime
>
> Use:
>
> @StartDaysDiff int,
> @EndDaysDiff int
>
>
> In the front end app take the desired date and do a DATEDIFF with the
> current date, then pass the date diff as a parameter as an integer
> rather than deal with the dates at all.
You could run into nasty surprises if the client and server are in
different time zones. Then again, if you instead of using the current
date as your base date, took a fixed date such as 1900-01-01, you'd be safe.
Then again, this is also confusing as 1900-01-01 is the base date in SQL
Server while in Visual Basic it's 1899-12-30.
And I don't really see how this relieves you from dealing with regional
settings on the client side. After all, the user inputs a date, and the
interpretation of 1/7/9 is different depending on where you are. And
to transform that to a number, you still have to interpret it.
--
Erland Sommarskog, SQL Server MVP, esquel@xxxxxxxxxxxxx
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
.
- References:
- Passing DateDiff rather than Actual Dates as Parameters
- From: laurenq uantrell
- Passing DateDiff rather than Actual Dates as Parameters
- Prev by Date: Re: STORED PROCEDURE - passing table name as a parameter
- Next by Date: big log file
- Previous by thread: Re: Passing DateDiff rather than Actual Dates as Parameters
- Next by thread: Regarding BCP utility
- Index(es):
Relevant Pages
|
