DateTime - Difference in Epoch between .NET and .NET Micro

This through me through a loop briefly, so I thought I would post a note here in case anyone else encounters the same problem.

I’m posting here as I only have a FEZ Domino to test it on, and I can’t be sure if the .NET Micro Framework documentation is just wrong, or if FEZ implements it against spec.


I’m doing some logging on a FEZ Domino and using the Ticks property as my timestamp in the log.

I have the need to read these logs on a computer.

In the .NET 4 Framework, Ticks is described here as:

[quote]A single tick represents one hundred nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond.

The value of this property represents the number of 100-nanosecond intervals that have elapsed since 12:00:00 midnight, January 1, 0001, which represents DateTime.MinValue. It does not include the number of ticks that are attributable to leap seconds.[/quote]

Meanwhile, in the .NET Micro Framwork 4.1 documentation, Ticks is described hereas:

But, on the FEZ Domino at least, this is incorrect.

As it happens (and despite what the documentation from Microsoft says), Ticks == 0L provides an epoch of January 1, 1601.

Therefore, should you need to convert Ticks from a FEZ Domino on a PC, you’ll want to add an offset of 504911232000000000L Ticks (01/01/1601) to get the correct time back on the PC.

We will look into it.

I ran into the same issue.

I think this came up before and yes there is some offset needed. I would think this is the same on any NETMF device?

I did a search of the forums but didn’t see it posted anywhere, so I thought I’d make a note of it just in case someone else runs into this…save 'em a few minutes of head scratching.

At any rate, if it works this way on any NETMF device, then Microsoft has their documentation wrong.

If it works as advertised on other NETMF devices, something is wrong with GHI’s implementation.

Either way, I thought I should make a note of it.

Maybe it was on GHI forum?

It is a bug in NETMF, Microsoft will fix it in next version.

Any update on this? It still wrong in NETMF 4.1.2821.0

Wow this is from over a year ago! If this was support to be fixed in 4.2 then 4.2 is there for you to try out