3 replies to this topic

[Cabadam]

Executed the following on my Netduino Plus (running the 4.2 RC1 firmware): Debug.Print(new DateTime(129597249849261120).ToString()); That printed: 09/05/2011 19:36:24 Looks good, basically what I expected. Now over in my full .NET 4.0 app (which is receiving that integer value from the Netduino): string str = new DateTime(129597249849261120).ToString(); That yields: 9/5/0411 7:36:24 PM They are exactly 1600 years apart?

[Chris Walker]

Hi Cabadam, I believe that the datetime "starting time" is different between .NET and .NET Micro Framework. If this is a potential compatibility issue for your project, I'd recommend posting a note over at netmf.codeplex.com. We never share DateTime values betwen devices/computers as integers...but I can see where this would be useful. Chris

[CW2]

Chris is right, indeed. The origin of DateTime in .NET Micro Framework is 1/1/1601, the documentation is incorrect and should be fixed in the upcoming 4.2 version (CodePlex issue #1003). The reason quoted from the source code:

/// NOTES: Why origin is at 1/1/1601.
/// Current civil calendar is named as Gregorian calendar after Pope Gregory XIII as he made adjustments
/// in 1582 (read more at wiki http://en.wikipedia....gorian_calendar). Rules governing
/// leap years were changed from then. Also in that year month October was 21 days instead of usual 31.
/// This poses a problem on calculating date/time difference, leap years etc before 1582 using simple math.
/// For example 1500 was a leap year using old method while it is not using new. But in reality, as part of the
/// history it was leap year. Default CLR origin 1/1/01 gives wrong date time from years before 1582. For example
/// dates like 10/6/1582 does exist in history (see wiki), while CLR managed date/time will not throw an exception
/// if you are to create that date. To stay safe side 1/1/1601 is taken as origin, as was done for Windows.

Also, the initial system time (in absense of any time sync, or built in clock) is 1/1/2009:00:00:00.000 (128752416000000000 ticks).

[Cabadam]

Ah, thanks to both. Since it is intentional, I'll just code in a +1600 years on the .NET 4.0 side of things to account for it (and guess I also need to remember to subtract when sending the opposite way). And thanks for pointing out the existing issue regarding the documentation - I won't open up another issue then.