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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon