UTCNow vs Now .NET call

[Bjarne Joergensen]

Hi

 

I need the UTC time and convert it to tics.

I use this code(LV2012/DotNet 2.0):

 

 

 

Why is the Now time(local) the same as UTCtime. There should be a difference of 2 hours!

 

I made a program in C# and it is showing the right time (2 hours between Local and UTC)

 

regards Bjarne

Edited April 3, 2014 by Bjarne Joergensen

[Rolf Kalbermatter]

Hi

 

I need the UTC time and convert it to tics.

I use this code(LV2012/DotNet 2.0):

UTCNow DotNet.png

 

 

 

Why is the Now time(local) the same as UTCtime. There should be a difference of 2 hours!

 

I made a program in C# and it is showing the right time (2 hours between Local and UTC)

 

regards Bjarne

 

Why not? The .Net DateTime structure has a property Kind which can have a value DateTimeKind.Utc or DateTimeKind.Local or DateTimeKind.Unspecified. LabVIEW timestamps are internally ALWAYS the number of seconds since midnight Jan 1st, 1904 UTC. So LabVIEW properly translates the .Net DateTime structure into its own Timestamp format and takes care about doing the proper translation depending of the DateTimeKind value in that structure. If you want to display UTC in the LabVIEW control you have to change the DisplayFormat of that control accordingly, not change the internal timevalue of the Timestamp.

 

I find it cleaner to change the property of the display element (or toString() method) than maintaining all kinds of extra flags with the timestamp itself although that does have some implications when you move timestamps between timezones. On the other hand maintaining also the relative timezone properties with each timestamp, while being more flexible, also requires a lot more data storage and all kinds of special case logic.

[Bjarne Joergensen]

Hi rolfk

Thank you.

I don't think I understand it all, but what I need is the UTC time in ticks and I can get that from .net.

I don't need the timestamp format, although it would be nice and easy to read:-).

I have made a .net dll and call it in labview and getting what I want.

 

regards
Bjarne

[Rolf Kalbermatter]

Hi rolfk

Thank you.

I don't think I understand it all, but what I need is the UTC time in ticks and I can get that from .net.

I don't need the timestamp format, although it would be nice and easy to read:-).

I have made a .net dll and call it in labview and getting what I want.

 

regards

Bjarne

 

UTC time in ticks is very unspecific. Ticks is simply an arbitrary unit with an arbitrary reference time. Traditionally a tick was the 55ms interval timer tick used under DOS and Windows 16 bit and even early versions of Windows NT used that timer tick. Newer Windows versions use a timer tick of 1ms internally but still have functions that scale that to 55ms. The reference time is usually the start of the machine.

 

Obviously when you talk about UTC you most likely mean a more absolute value than the start time of the computer. Still, the reference time is very arbitrary. While the .Net DateTime version uses midnight, January 1, 0001 (supposedly UTC but the .Net DataTime.Tick() description is entirely unclear about this) with 100ns resolution, LabVIEW uses midnight Jan 1, 1904, GMT as reference with a 1s resolution. Windows itself has several different formats such as the C runtime time_t which is typically referenced to midnight Jan 1, 1970 UTC with a 1s resolution (same as what most Unixes or more specifically the C runtime library on Unix uses). But Windows also has a FILETIME format which is referenced to midnight Jan 1, 1601, UTC with a resolution of 100ns.

 

Now LabVIEW's timestamp format supports in fact fractional seconds with a resolution of 1/2^32 s and internally retrieves its values from a FILETIME value so if you convert the timestamp into a floating point value you still get about 1/2^20 s accuracy there for the foreseeable future which is about 1us. So if your reference time doesn't have to be specifically the .Net DataTime value all you would need to do is likely to simply convert the LabVIEW timestamp into a floating point value and you can forget about any external DLLs.