views:

1189

answers:

3

I want to store a a c# DateTimeOffset value in a SQL Server 2005 database.

Sql 2008 has this as a built-in-type, but SQL Server 2005 does not.

The DateTimeOffset structure has a DateTime value wich I store as DateTime, an an Offset property (of type TimeSpan). Since this is the time zone relative to UTC, presumably it is usally at a whole number of hours or half-hours.

Suggestions on how best to store this in a SQL Server 2005 database?

+1  A: 

store the datetime as datetime and the offset as milliseconds (bigint)

Manu
+6  A: 

It's not a good idea to assume that an offset is a number of hours or half-hours - there are certainly quarter-hour timezones around.

Using milliseconds for the offset is probably the most flexible, but I'd argue that minutes is a lot easier to read. If you're ever going to look at the "raw" data in the database, it's easier to understand value 60 = 1 hour than 3600000. I can't imagine you really needing fractions of minutes as the offset.

Jon Skeet
+3  A: 

Normalize all DateTimeOffsets to a common offset, preferably UTC. Then just store the DateTime as usual. Upon extraction restore the offset, which should be a constant. This doesn't retain the originating offset but the offset is ambiguous to a timezone anyway.

If you actually need to know the date/time origin, then you'd need to store some timezone information. This is because a simple offset can't unambiguously represent the origin of a time. Please see (the somewhat confusing) MSDN documentation about Choosing Between DateTime, DateTimeOffset, and TimeZoneInfo.

JarrettV
Agreed - store dates as UTC and only worry about timezones and DST offsets at the moment of presentation to the user.
J c
I disagree. The DateTimeOffset structure (in C# and SQL 2008) stores time as either UTC or local time + offset. Storing a UTC time + offset would reverse that relationship and only cause confusion.
Robin M