DateTime and DST | Tech Off

ploe

Does the .net DateTime struct consider DST?

Lets say I have a DateTime dt that is set to a date two hours before we set our clocks forward. Then I add 5 hours to dt. Would the DateTime add function consider DST or would the add be an hour off?

W3bbo
The Master of Baiters

The DateTime structure is a simple wrapper around a 64-bit integer (Ticks since Jan 1 1970 IIRC), so adding 5 hours has the effect of adding 5*60*60*(howmany ticks in a second) to the internal number.

I think if you want localisation support with dates and times you should use the DateTimeOffset class instead.

ploe

In reply to W3bbo

#Aug 28th, 2008 @ 10:18 AM

Thanks. DateTimeOffset does what I want it to.

Here's a sample just in case someone else has this problem in the future...

// 11/2/2008 at 2:00 AM we change our clocks back an hour
dt = new DateTimeOffset(2008, 11, 2, 1, 0, 0, new TimeSpan(-4, 0, 0)); // 11/2/2008 1:00 AM
dt = dt.AddHours(3); // add 3 hours
Console.WriteLine(dt.LocalDateTime); // DateTime would output 4:00 AM and this
// outputs 3:00 AM (what it should be) Smiley

Triynko

In reply to ploe

#Aug 29th, 2008 @ 9:10 AM

DateTimeOffset is not even a solution for bridging the UTC to Local gap, since it's basically asking you for the information you want to compute (i.e. the offset between a given local time and a UTC time. In order to store a local time, you need to know all the individual offsets from UTC, including the time-zone offset AND whether any DST offset is present. Otherwise, you do not have a complete record of the local time.

It's nice that you can come up with an arbitrary offset like "4 hours" there, but normally... such an offset would be computed by subtracting two DateTime values, which will return an incorrect TimeSpan (i.e. incorrect number of hours) if computed between two ambiguously specified local times.

staceyw
Before C# there was darkness...

In reply to Triynko

#Nov 4th @ 2:49 PM

@Triynko. You do loose the actual timezone, however there is still much love:

1) You always have the absolute time in UTC. So you can convert it to any known timezone easily - even on the server.

2) You have the local time as offset from UTC. So a server report, for example, can still display local time in respect to users orginal point in time.

3) Unlike DateTime, it is always unambiguous as you have base utc. And datetimeoffset is stored as a utc on sql server 08 for index and compare.

4) Math and compare is done as utc which avoids a whole class of issues.

Only thing you can't do is tell which timezone it was. Normally, however, something like local time preference is handled locally on the client or as a report parameter. So you should be able to get to anything you need.