Conversion of time-stamp into string produce 1 h offset

[Olli]

Hello,
since I upgraded from 8.1 to 8.5.1 the "format into string" function gives a 1 h offset compared to the time-stamp input (see picture in the doc). The attached SubVI's are running on a Fieldpoint system. The fieldpoints are set to a local time with automatical DST changing disabled. The timeserver is also running without DST changing.  I found this penomenon only with the fieldpoints. On the normal PC the subVI works fine.
Maybe I should think about another conversion possibility, but this problem wasn't there before upgrading (never touch a running system???....No way!)
What could be the problem?
Thanks and have a nice day
Olli

[MikeS81]

Hi Olli,

you can also use the "Format Data/Time String" function.

Mike

[Olli]

Hello Mike,
thanks for the reply! I tried it with the "Format Date/Time String" function...the result is the same, but I can manipulate the result by setting the function to UTC and add the 1 h offset to the original time-stamp....that could be a solution, but I don't really like it not to know, what goes wrong (see the pics in the attached doc)
I chose the string conversion function because I assumed, that there is only a conversion of the input value and not any relation to a cerain time zone setting (which seems to be correct, if I can trust the fieldpoint settings in MAX). The fieldpoiunt drivers and software was allso upgraded with the latest versions.
Offtopic: I hope the person who invented DST will be forced to pay heavily for the mess he/she did in the world!
ciao,
Olli

[Jim_M]

Hi Olli,

       I hope you are having a good day.  I took a look at your code and screenshots and have had a difficult time trying to figure out what may be going on with your code.  I tried running your code and did not have the same problem that you've experienced.  Are you binding those timestamp controls to variables on your fieldpoint?  Is there anyway that you can replicate your error so that you can still see it once you close and reopen LabVIEW?  If you find a way to do this, please post your code.  I agree that it seems like this is probably related to Daylight Savings, but I'm not sure where the source of this problem could be.  Have you tried using a shared variable instead of binding controls?  Have a great day and good luck.

[Olli]

Hello Jim,
thanks for your answer!
Yes, I can always replicate this error. I closed LabVIEW rebooted the whole system (PXI and Fieldpoints)..and it's still there. In the main VI running on the fieldpoint I connected the time stamp outut of the posted SubVI to a variable. I can change this to, but I don't think it will help. The document  I posted shows a simple VI running on the same fieldpoint without any connections to a variable. When I have this same VI running on the PXI, there is no problem at all. That's why you have difficulties to figure out the problem with the posted VI's...and therefore I posted screenshots, too.
During the next week, I will have a third fieldpoint system connected to the measurement network. This Fieldpoint had no problem with the time stamp conversion when I checked its functionality with my office PC in our office network, but it wasn't used before that time with any LabVIEW applications in older versions.
Maybe it's not a LabVIEW related problem, but a fieldpoint related one?
Today I need to stop the measurement again because of hardware installation. I will take the chance to try several things...maybe reinstallation of the fieldpoint drivers?
Have a nice day!
Olli

[Olli]

Hello,
I reinstalled the Fieldpoint Software on the two FP systems...the difference of one hour between time-stamp and the converted string remains.
Today I connected the third FP system to the measurement network ( remember the one, which had no problem with the conversion in the office network). Look at the screenshot what happened here. the left VI is running on the fieldpoint controller the right VI is running on the PXI.
I just changed the TCP/IP.
The local setting on the PXI and the fieldpoints are the same. When I change the local settings on the fieldpoint to UTC, then there is no difference between the time-stamp and the string....but the time-stamp remains GMT+1h even when the local setting is UTC!
I could leave it like this and then check when there is the next change to wintertime...but I really don't like this.
Have a nice day
Olli

[Ben]

Olli posted;

"Offtopic: I hope the person who invented DST will be forced to pay heavily for the mess he/she did in the world!"

I believe that was Ben Franklin who originally put forth that idea as a away for farmers to get more hours in the day.

Ben

[Olli]

OK...besides the Daylight Saving Time Ben Franklin invented also very good things like the lightning protection...anyway he's gone from the earth and hopefully the DST will follow in the near future  😉

It seems, that the local time settings on the FP have no affect to the FP clock, when it is synchronised to a time-server.
I tried several different local settings on the FP and the time-stamp remained always the same as the time-server (here the PXI). The string conversion followed the local settings with 1h difference to UTC (what is the local setting on the PXI).
So, I will set all FP's to UTC and the problem should be somehow solved at least temporarly...hopefully also in the wintertime.

Best wishes
Olli

[TCPlomp]

Hi Olli,

what if you set the 'UTC' boolean of get date-time string to True?
If you use the 'Format into String' function, you can get the offset from UTC as well.

Ton

PS why post your screenshots as RTF? They are very big to download.
Try the Code Capture Tool it is great for this purpose, you select the part you want to capture, start the tool (Tools->Code Capture Tool), review your setting (FP-all, BD-all, Clipboard-FileName), finish the capture.
Then you switch over to your internet browser, in the file dialog you past the file name from the clipboard and the file is attached.
To download

[Matthew_Williams]

Hi Olli.  A couple of suggestions for Fieldpoint time:

1) We set all Fieldpoint nodes to UTC, no DST.  This makes it easier for me to remember what TZ the data is from 😉

2) I think LV always handles timestamp types in UTC, converting automatically, unless directed otherwise, at the user
interface.  This is the programming model we follow and it seems to help me keep things straight.

3) Make sure that if you use the time server setting in the Fieldpoint controller, the time server is supplying UTC.  I
_think_ this is the case with a windows pc with a timezone set.

4) We don't use the time server setting because the corrections seem to cause random discontinuities in our timestamp data.
Instead we send the current time in the application data stream between the pc and the fp and then use the RT utilities to
set the time.  You still have the possibility of discontinuities, but at least you know when they may happen and why.

5) The Fieldpoint controller handles time much the same way as a pc, with both hardware and software clocks.  The
LV time functions all seem to use the software clock, the FP Read.vi, etc., seem to use the hardware clock.  Just as
in a PC, the hardware and software clocks will diverge, potentially causing further jitter or discontinuities, depending
on which part of your code gets its timestamp from where.  The best solution we have found is to create an LV2 global
that gets updated everytime we do a hardware read with the hardware timestamp, then use this global as our timesource
for the rest of the application.  Note that 1 second accuracy is adequate for our application; we care much more about proper
sequence than we do about absolute differential.

Hope there is something useful in here for you.

Matt