[CSHARP-729] Serializing a class with two dates to BsonDocument creates wrong value in one date Created: 18/Apr/13  Updated: 20/Mar/14  Resolved: 18/Apr/13

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.8.1
Fix Version/s: None

Type: Bug Priority: Blocker - P1
Reporter: Paul Brower Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: BsonDocument, DateTime, Serialization
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Professional 64-bit. Visual Studio 2010 SP1. .Net Framework 4.0. Central Time Zone.


Backwards Compatibility: Major Change

 Description   

The following code will convert both dates to UTC, but with the same hour! This output is produced:

2:52:26 AM (Notice the hour)
3:05:26 AM (Notice the hour)
2013-03-10T08:52:26Z (shows wrong hour. Should be 7, not 8)
2013-03-10T08:05:26Z (this is correct)

public class TestDateSerialize
{
public DateTime EntryDtTm

{ get; set; }
public DateTime ExitDtTm { get; set; }

}

public void testSerializeDateTime()

{ var obj = new TestDateSerialize(); obj.EntryDtTm = Convert.ToDateTime("3/10/2013 02:52:26"); obj.ExitDtTm = Convert.ToDateTime("3/10/2013 03:05:26"); var doc = obj.ToBsonDocument(); Console.WriteLine(obj.EntryDtTm.ToLongTimeString()); Console.WriteLine(obj.ExitDtTm.ToLongTimeString()); Console.WriteLine(doc["EntryDtTm"].AsBsonValue); Console.WriteLine(doc["ExitDtTm"].AsBsonValue); }

 Comments   
Comment by Robert Stam [ 18/Apr/13 ]

Glad to help!

Comment by Paul Brower [ 18/Apr/13 ]

My colleague and I are amazed at how quickly you determined and responded to this issue! Thanks. We'll figure out how to deal with this on our end. Please close this ticket.

Comment by Robert Stam [ 18/Apr/13 ]

In 2013 Daylight Saving Time started at 2am on March 10. At 2am clocks were set forward one hour, so the next minute after 1:59am is 3:00am.

Because the clock was set forward one hour, times from 2:00am to 2:59am are not valid.

The first test time you used, "3/10/2013 02:52:26", falls into this invalid range. .NET doesn't throw any exceptions when you use these invalid times (and in any case, whether they are valid or not depends on what time zone you are in and whether you observe Daylight Saving Time or not). What .NET does with these "invalid" values is assume that they actually correspond to one hour later. So when .NET sees the invalid 02:52:26 it assumes you really meant 03:52:26.

I don't think this is a diver bug or anything we need to do anything about. It is really just an idiosyncrasy of how .NET interprets time values that are not valid due to Daylight Saving Time.

Generated at Wed Feb 07 21:37:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.