|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Thursday, April 11, 2013 10:55 AM
Points: 37,
Visits: 402
|
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945,
Visits: 2,782
|
|
Instead of handling temporal data as strings (like we did in 1950's COBOL), instead of constructing a table of constant values over and over with procedural code , why not write SQL as if it were a declarative language that is good at table look-ups? Since one-statement UDFs can be done in line, why use all that procedural code to prevent any optimizations?
CREATE FUNCTION UTC_DST_Displacement (@in_my_datetime DATETIME) RETURNS INTEGER AS BEGIN RETURN (SELECT (CASE WHEN @in_my_datetime BETWEEN dst_start_time AND dst_end_time THEN +1 ELSE 0 END) AS answer FROM (VALUES (CAST ('1990-04-01 02:00:00' AS DATETIME), CAST ('1990-10-28 02:00:00' AS DATETIME)), ('1991-04-07 02:00:00', '1991-10-27 02:00:00'), ('1992-04-05 02:00:00', '1992-10-25 02:00:00'), ('1993-04-04 02:00:00', '1993-10-31 02:00:00'), ('1994-04-03 02:00:00', '1994-10-30 02:00:00'), ('1995-04-02 02:00:00', '1995-10-29 02:00:00'), ('1996-04-07 02:00:00', '1996-10-27 02:00:00'), ('1997-04-06 02:00:00', '1997-10-26 02:00:00'), ('1998-04-05 02:00:00', '1998-10-25 02:00:00'), ('1999-04-04 02:00:00', '1999-10-31 02:00:00'), ('2000-04-02 02:00:00', '2000-10-29 02:00:00'), ('2001-04-01 02:00:00', '2001-10-28 02:00:00'), ('2002-04-07 02:00:00', '2002-10-27 02:00:00'), ('2003-04-06 02:00:00', '2003-10-26 02:00:00'), ('2004-04-04 02:00:00', '2004-10-31 02:00:00'), ('2005-04-03 02:00:00', '2005-10-30 02:00:00'), ('2006-04-02 02:00:00', '2006-11-29 02:00:00'), ('2007-03-11 02:00:00', '2007-11-04 02:00:00'), ('2008-03-09 02:00:00', '2008-11-02 02:00:00'), ('2009-03-08 02:00:00', '2009-11-01 02:00:00'), ('2010-03-14 02:00:00', '2010-11-07 02:00:00'), ('2011-03-13 02:00:00', '2011-11-06 02:00:00'), ('2012-03-11 02:00:00', '2012-11-04 02:00:00'), ('2013-03-10 02:00:00', '2013-11-03 02:00:00'), ('2014-03-09 02:00:00', '2014-11-02 02:00:00'), ('2015-03-08 02:00:00', '2015-11-01 02:00:00') ) AS DST_Periods (dst_start_time, dst_end_time) ); END;
Books in Celko Series for Morgan-Kaufmann Publishing Analytics and OLAP in SQL Data and Databases: Concepts in Practice Data, Measurements and Standards in SQL SQL for Smarties SQL Programming Style SQL Puzzles and Answers Thinking in Sets Trees and Hierarchies in SQL
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Thursday, April 11, 2013 10:55 AM
Points: 37,
Visits: 402
|
|
Thank you for your response.
The optimization in this case is negligible, but I do see your point. The downside to your script is that the dates are hard-coded, and one has to remember to enter in the new dates as time goes on.
The main purpose of this script is for those that do not have lookup tables, and need a quick solution to converting dates while adjusting for daylight savings time.
|
|
|
|