topic Re: UTC +-0.001 seconds in LabVIEW

UTC +-0.001 seconds

ogk.nz — Thu, 16 Mar 2017 21:18:22 GMT

This is a little bit of two things, one I want to figure out what is going on with this little snippet for curiosity sake and also, see if anyone has any better ways of dealing with this then the Goldbergian way I currently am.

I have a server that only returns timestamps in the specified text format and UTC time so I need a way of converting that to local time for ease of reading, so after faffing about for a bit I found the below, although it has an interesting problem, it loses 0.001 seconds on certain values.

.256 = .255

.257 = .256

.258 = .258

.259 = .259

.260 = .259

Not a big deal as I'll never be working to that time accuracy, but just interesting. Let me know your thoughts.

Re: UTC +-0.001 seconds

RavensFan — Thu, 16 Mar 2017 21:27:34 GMT

Can you show more decimal places on your indicators?

My thought is that timestamps are essentially a special variation of a floating point double precision. You probably already know by now that not all numbers can be represented exactly in binary. You may be running into this where the act of converting is not quite giving you the same result back due to the tiny errors in the resolution of floating point numbers.

Beyond that, I'm not sure you need to do as much as you are doing to convert a time to appear in local time. I just don't have the time (ha ha) at the moment to experiment with it.

Re: UTC +-0.001 seconds

altenbach — Thu, 16 Mar 2017 21:52:12 GMT

If you remove the two "to DBL" and subtract the two timestamps directly, things seem to work better. Try it.

Re: UTC +-0.001 seconds

ogk.nz — Thu, 16 Mar 2017 21:59:34 GMT

@Ravens

I had tried using the Time version originally but it doesn't seem to work properly with DST for some reason, but I do feel like there must be a better way to do this.

@Altenbach

It seems better, but oh do I not like the sight of coercion dots....

Not sure which is the lesser of two evils here. And my understanding of coercion dots was that they indicated a hidden type conversion, so interestingly, its not the conversion to float itself, but simply the position of the float conversions.

Re: UTC +-0.001 seconds

altenbach — Thu, 16 Mar 2017 23:00:06 GMT

Well, coercion dots are not harmful. If a coercion occurs, it does not matter if it is implicit or explicit. 😄

(see also this long discussion that shows that omitting explicit coercion (and thus having coercion dots!) is sometimes preferable. Go read it! I just added a link to our discussion :D)).

Back to the current problem, I had the crazy idea to tell it that the original time is in UTC (by replacing the "Z" with 00:00:00 or -00:00:00 and reading it with %z, but it obviously does not seem to work. Maybe I am doing it all wrong. This is not my field of expertise. 😄

Re: UTC +-0.001 seconds

ogk.nz — Thu, 16 Mar 2017 23:18:14 GMT

Looking at your use of %z reminded me of something I saw once upon a time in the date format so I figured I might try it.

Replacing %< >T (Absolute time container) with %^< >T (Universal time container) results in the same reading as returns from the Seconds/Date-Time/Seconds conversion, off by an hour. So it looks like there is something about LV that doesn't quite handle the DST properly when going back and forth to UTC.

Re: UTC +-0.001 seconds

billko — Thu, 16 Mar 2017 23:26:55 GMT

Would it be fair to say that the obsession with coercion dots came from the CLD exam frowning upon them?

Re: UTC +-0.001 seconds

RavensFan — Fri, 17 Mar 2017 04:51:45 GMT

Why wouldn't this work?

Input string is assumed to be UTC. It converts it to a timestamp which is assumed to be local time. It also determines time zone, and adds that to the result, so the time in the time stamp indicator is now compensated t local time.

I do see one flaw with this. The DST shift could fail if UTC time is at a time that if it was local, time changed would have occurred, but it would subtract back to a point of time where the time change had not occurred yet in your local time. So that would be a few hours in the spring and a few hours in the fall. But with a bit more code to look at the time zone offset after the addition, the hour could be added back in or taken out. (I did not include this scheme in the snippet.)

I still think there is another way that LabVIEW would handle this better based on format strings. I'm just not sure how yet.

Re: UTC +-0.001 seconds

jamiva — Fri, 17 Mar 2017 11:02:34 GMT

Here is an alternate way to convert from local time to UTC time. I've used this call to the kernel for many years without any issues (at least through Windows 7). Just "add" the UTC offset to go from UTC time to Local. I don't know if this is any better/faster, but you only need to store one numeric value rather than doing a lot of string conversions.

The only issue I see is the same one RavensFan mentioned: If you make the call to the kernel just before DST changes (at 2am) you will still have the old offset value until you call the kernel again after 2am. This will only happen twice a year Nov 1 and March 3 (or not at all if you live in Arizona, Hawaii, Puerto Rico...)

I forgot where I got this code, so I apologize for not giving him/her credit.

Re: UTC +-0.001 seconds

billko — Fri, 17 Mar 2017 14:17:05 GMT

This is courtesy paul_cardinale:

This calculates the offset of local time from UTC. It is fully DST compatible.

Re: UTC +-0.001 seconds

rolfk — Fri, 17 Mar 2017 18:10:33 GMT

Actually using %^<>T as format string container as mentioned by ogk.nz treats the string directly as UTC. However I found something else on my computer which sounds strange. I had to remove the %p format specifier and instead use the 24 hour clock here, in order for the Scan from String function not to return with error 1 (argument error). Also using %p in a Format to String function produces an empty string.

And for some reasons I seem not to be able to change the data and time format from the HH:mm:ss on my Windows 10 system. Maybe it's one of the settings our company feels should not be changed, after all who the heck still uses this pretty confusing AM/PM clock anymore?

But even changing the country setting from Netherlands to United States didn't seem to allow LabVIEW to use the %p format specifier on my computer. So definitely something else to consider for people who need their application to run in more countries than just their own.

Re: UTC +-0.001 seconds

RavensFan — Fri, 17 Mar 2017 20:46:06 GMT

This all sounds vaguely familiar. I want to say some message from about a year ago.

I wonder if I can come up with the right keywords and find it.

EDIT:

Maybe this is it.

http://forums.ni.com/t5/LabVIEW/Scan-from-String-to-get-Timestamp-Problem-in-LV-2012/td-p/2755506

The reason is seemed familiar is because it is one of the relatively few posts I started. And it was actually about 2 years ago.

It talks about errors in the time and scan from string functions, but related to 2 and 4 digit years, not AM/PM vs. 24 hour clock.

I'll have to keep looking to see if there is anything more directly related.

EDIT #2:

Found this from 6 years ago. More relevant.

http://forums.ni.com/t5/LabVIEW/scan-from-string-does-not-recognize-AM-PM-flag/td-p/1479438