LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Clear cached timezone in LabVIEW

I have a string that is already in UTC time. When our application starts up, we change the timezone of the PC to GMT time. But, it looks like LabVIEW's scan from string does not see this update until I restart LabVIEW. However, I can get it from .NET. I was hoping the TimeZoneInfo.ClearCachedData() method would work for LabVIEW but it looks like it isn't. Is there any way around this?

 

 

timezone-update.png

 

 

 

0 Kudos
Message 1 of 10
(2,691 Views)

Channeling DKnutson...

 

No

 

Ben

 

Spoiler

 

At least that is what I recall from somewhere in space and time.

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 10
(2,688 Views)

@Ben wrote:

No


well that sucks

0 Kudos
Message 3 of 10
(2,680 Views)

@GregFreeman wrote:

@Ben wrote:

No


well that sucks


Don't give up hope!

 

Maybe I am wrong. But I seems to recall Rolf maybe explaining it is a OS thing that is only checked when LV launches???

 

Edit:

It was tst but Rolf was involved in the thread. see here.

 

Edit2:

On further thought it is a good thing. Getting the timezone requires a call to the OS to get the setting. It would be a performance hit if we ahd to invoke the OS everytime we had to format a timestamp.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 10
(2,672 Views)

What are you really trying to do?  Why are you changing the time zone of the PC to GMT?  And what is the time zone it is in now?

 

If you are starting off with a string, then it is really a bunch of characters with no inherent timezone associated with it.  The timezone associated with those characters are whatever you happen to say it is.

 

If you are trying to make sure the results of calculations, or the display of a timestamp on the LabVIEW front panel is in GMT even though the string data is not associated with GMT, then there should be a number of ways to handle that without messing with the timezone of the PC.  Either through display settings of a timestamp indicator, or adding or subtracting time based on the PC's actual timezone.

 

Honestly, I would hate it if a program I ran decided to change the timezone of my PC.  The program should be robust enough to handle different time zones within code.

0 Kudos
Message 5 of 10
(2,649 Views)

The requirement is there because these systems are being shipped around the world and doing some stuff with satellites. At startup they will get the time from a satellite and set the system time to match. It isn't something that will be changed dynamically as the system runs. I can't really argue the requirement so it is what it is.

 

I agree that every call to scan from string shouldn't get the time zone. But it would be nice if I had control over refreshing it if I needed to.

 

And, it's true I can handle it in software, but when there is a function that already manages that, if I could get the right timezone into LabVIEW, I would prefer to use that option and not mess with DST/no DST etc etc

0 Kudos
Message 6 of 10
(2,617 Views)

So, I think I had a major brainfart....

 

It hit me like a ton of bricks...the display for the timestamp indicator has a default format string which is local time, not UTC time, by default. So when I was debugging and sticking indicators around as I converted back and forth from strings to timestamps, it seemed like my timestamps were wrong. But then I realized it was just the display on the indicator itself showing my timestamps in locale time. 

 

Here are two timestamps indicators with different formatting after being converted explicitly to UTC date/time

 

timestamp-formatting.png

 

 

0 Kudos
Message 7 of 10
(2,600 Views)

The Timestamp value in LabVIEW is always meant to be in seconds since Midnight, Jan 1, 1904 GMT. GMT for LabVIEW purposes is really the same as UTC.

The conversion to and from Strings is where you have to determine what Timezone you want to have it in and then sticking to it for a particular (sub) system. The Format into String has a specific format for Timstamps with “%<detail format>T” for local Timezone and “%^<detail format>T” for UTC. Not fully sure if the Scan from String supports that too as I’m not usually using it for Timstamps (you want to limit such complications as much as possible to one side only, converting back and forth will sooner or later kill your sanity in trying to make this work under all possible engineer imposed complications). And I’m on mobile so can’t check atm.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 10
(2,588 Views)

@rolfk wrote:

(you want to limit such complications as much as possible to one side only, converting back and forth will sooner or later kill your sanity in trying to make this work under all possible engineer imposed complications).


Totally agree. I refactored so at the very lowest level it converts the UTC strings I get to a timestamp in a single place, and updated everything on my model layer to use those timestamps. Now it's up to the consumer of the timestamp to do what it wants with it.

 

To reiterate though, I believe most of my confusion came from the timestamp indicator displaying things in local time. For some reason in my head I was thinking it should be displaying UTC, since after all, I just converted UTC time to a timestamp. But of course the computer doesn't know that unless I tell it to display that way.

0 Kudos
Message 9 of 10
(2,560 Views)

@GregFreeman wrote:

@rolfk wrote:

(you want to limit such complications as much as possible to one side only, converting back and forth will sooner or later kill your sanity in trying to make this work under all possible engineer imposed complications).


Totally agree. I refactored so at the very lowest level it converts the UTC strings I get to a timestamp in a single place, and updated everything on my model layer to use those timestamps. Now it's up to the consumer of the timestamp to do what it wants with it.

 

To reiterate though, I believe most of my confusion came from the timestamp indicator displaying things in local time. For some reason in my head I was thinking it should be displaying UTC, since after all, I just converted UTC time to a timestamp. But of course the computer doesn't know that unless I tell it to display that way.


Yep.  It's just like displaying text as text, backslash, or hex.  It's all the same to the computer; it just looks different to the human.  🙂

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 10
(2,545 Views)