LabVIEW
UTC +-0.001 seconds
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.
If you remove the two "to DBL" and subtract the two timestamps directly, things seem to work better. Try it.
@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.
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. 😄
Would it be fair to say that the obsession with coercion dots came from the CLD exam frowning upon them?
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.
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.
This is courtesy paul_cardinale:
This calculates the offset of local time from UTC. It is fully DST compatible.
