GSquared (7/10/2012)
Should the code be sensitive to Daylight Time vs Standard Time (US), or should it rely on "EDT" vs "EST" in the input?If sensitive without the input being modified, should it take into account prior definitions of the begin/end dates for those transitions, or just work off of current rules?
Will it take a location into account (like Arizona, which doesn't do Daylight Time; same for Hawaii)?
Or just 3 inputs: Time, ZoneFrom, ZoneTo?
How about backwards compatibily with SQL Server 2005 and before, which don't have the Time datatype, and would have to provide DateTime?
Or, since it's an article, should it go into all of these options, and provide sample code for each? The more complex options (geo-sensitive, sensitive to changing rules by year of input value, etc.) might be pretty complex.
I think this will be a bit complex. Yes, I'd like to take into account the EST v EDT. I don't know that I'd go back in time to the old DST time changes (Apr/Oct) but work with new ones.
No backwards compatability with pre 2008.
Sample code, and a function to use. If there's something that can't be covered or seems out of scope, say that.