LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timestamp always converted to UTC?

Solved!
Go to solution

 

In applying the "Get Date/Time" function and "Date/Time to seconds", it looks like they force UTC after conversion, even if the option for UTC is FALSE.

 

I would like to have the actual system date and time available (that accounts for DST and timezone as shown on my PC)  at the timestamp output, but instead I keep getting a value for the timestamp that (I assume) is UTC. When I probe the timestamp output, or the cluster output, it looks correct. However upon evaluating the timestamp number, it is always off by what looks like the DST and timezone difference (exactly 5 hours).

 

I have tried two  different methods and find the same results;

1) Output of "Get Date/Time" function directly (which states the timestamp will be Universal Time in its contextual help file)

and

2) Converting the timestamp to a cluster and reconverting it timestamp (as shown in picture).

 

In the example picture attached, notice that the cluster output (Probe 25) shows the correct hour (16) when broken down and the timestamp probe (Probe 26) looks correct.

 

However, when the timestamp of either the "Get Date/Time" function or the "Date/Time to seconds" function is converted to U32, the time changes to what looks like UTC time as the timestamp 3485539686 (Probe 28) has the 5 hour offset (21 hours as shown in the Excell sheet calculations included in the picture).

 

I do not want to simply subtract 18,000 seconds to account for this difference (as changes in DST or timezone could cause problems). I would like the actual PC time to be used for the array build.

 

How can I do this?

Why do the probe points show the correct system time, but right after timestamp is coverted to U32 it looks like UTC?

 

 

 

0 Kudos
Message 1 of 20
(5,227 Views)

You are confusing display with internal values.

 

LabVIEW always stores the value as a UTC timestmap.  That function basically either converts from or to a time cluster, which allows you to specify the cluster is local or UTC time.  Internally, LabVIEW still stores the timestamp as UTC.

 

There are benfitis to this as someone who uses this value in another timezone can have the timestamp show up in their own time zone.

 

If you want to keep it in your time zone only (which I wouldn't suggest), you'll either need to break the cluster up and build the U32 yourself, or call some WinAPI functions to get info about the time and do the subtraction/addition to convert the UTC timestamp to local timestamp.

0 Kudos
Message 2 of 20
(5,210 Views)

 

Thank you for confirming that LV stores the timestamp in UTC.

 

Yes, I would like the timestamp to be in local time. I do not see any functions in LV to handle timezone and DST though.

Still searching for a method in LV....

Any ideas on how best to do that? 

 

I don't want to prompt the user for timezone and DST info, as that should already be available on the system. It seems strange that LV displays the timestamp correctly (local time) but does not store it that way.

 

BTW, this is for an app already in use. It is a known issue that the time is off by 5 hrs. This VI creates a payload containing the time in an array with other data that is then sent to another device. So I would like to simply account for DST and timezone in this frame and keep the formatting, if possible. 

 

I am hoping I don't need to reinvent a timestamp format here as it is only this LV app that is producing an offset while everything else in use with this device is not.

 

 

0 Kudos
Message 3 of 20
(5,189 Views)
Solution
Accepted by topic author Circuitmage

You can use GetTimeZoneInformation to get the bias for the time stamp and add/subtract it out.  It doesn't look like I have had to code that WinAPI call up yet, so I cannot provide it for you.  The return value also tells you daylight savings.

 

Alternatively, you can take your timestamp as you have done and convert it into the cluster and back again to determine the offset.  I only did some basic testign with this, so don't know if it works in all use cases.  The WinAPI method would be the most robust.

 

Time Offset.png

 

This Actually completes botches the dates up, but does return the correct offset.

Message 4 of 20
(5,176 Views)

You can do a search on "UTC Timestamp."  I think there are several results that might be helpful to you.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 20
(5,141 Views)

 

 

Lol

 

Of course, that was my first action. I did not find much.

 

I was waiting for someone to post that.

0 Kudos
Message 6 of 20
(5,133 Views)

@Circuitmage wrote:

 

 

Lol

 

Of course, that was my first action. I did not find much.

 

I was waiting for someone to post that.


It wasn't an automatic response.  I thought I saw several results that could help.  I guess I'm not understanding what the eventual goal of your conversion is.  If I wanted to use a timestamp, I'd just use the absolute timestamp value.  If I was using it for something a human would read, I'd just convert it to a string.

 

It's not at all unusual that the LabVIEW timestamp is in UTC, since that is the world standard.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 20
(5,116 Views)

Why would you want to tinker with the internal value of the timestamp at all? Doing so will certainly give you troubles a few months from now where you start to mix your understanding of what you did with what LabVIEW normally does, and another developer trying to make a seemingly small change to your application will be swearing nasty mantras at the original developer of this application. The concept of one universal time in a system, that only gets translated to the desired timezone value for presentation purpuses (displaying to humans), is the most simple when dealing with a complex system like time. Anything else adds unneccessary complexity that will cause problems sooner than later.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 20
(5,097 Views)

 

1st, thanks for the suggested methods stated above. I only have access to the LV development package at work, so I have not yet had a chance to try the suggestions yet.

 

2nd, I am sorry if I was not specific enough to provide more information. If stating I would like to keep the method shown in the picture as intact as possible and that I need the local time added to the array data is not enough, then I cannot state anymore details.

 

@rolfk,  I can not argue about the validity of my problem, only look for solutions. I believe it is valid. If there is no solution based on the limitations of LV then I will leave it at that.

0 Kudos
Message 9 of 20
(5,069 Views)

@Circuitmage wrote:

 

1st, thanks for the suggested methods stated above. I only have access to the LV development package at work, so I have not yet had a chance to try the suggestions yet.

 

2nd, I am sorry if I was not specific enough to provide more information. If stating I would like to keep the method shown in the picture as intact as possible and that I need the local time added to the array data is not enough, then I cannot state anymore details.

 

@rolfk,  I can not argue about the validity of my problem, only look for solutions. I believe it is valid. If there is no solution based on the limitations of LV then I will leave it at that.


He's just trying to stop you from driving the bus off the cliff.  Once you manipluate a timestamp like that, it loses its meaningfulness.  It no longer represents the amount of seconds elapsed since 01/01/1904.  If it is not meant to be seen by a human, it shouldn't matter about the format (because there is no format).  If it IS to be seen by a human, just convert it to a string for the report.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 20
(5,064 Views)