LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Scan From String" ignores time zone

Solved!
Go to solution

Well, maybe things are more subtle, but I still only get the correct time with my version (using two different websites):

 

altenbach_0-1680293320790.png

 

NDt.png

My guess is that the timezone cluster correctly normalizes the minutes if the hours are negative....

 

A simplified (but for me wrong!) version that gives the same as your code would be as follows:

 

altenbach_1-1680294111496.png

 

 

 

0 Kudos
Message 11 of 38
(1,035 Views)

@JÞB wrote:
Have you tried replacing the <>T with <>t in the scan from string format specifier?

 

Since the receives string from the external device is as follows, that would not scan correctly at all!

(Scanning with a <>t would return a DBL, not a timestamp.)

altenbach_0-1680294454383.png

 


@JÞB wrote:
And yes, CA meant to subtract 5 hours and 30 minutes instead of 4:30.  Must have been a Sr. Moment. .

Ah, age shaming! You're not quite a spring chicken either. 😄

 

Apparently, the time cluster correctly does the correct rotation for the minutes if the hours are negative. See my post above.

0 Kudos
Message 12 of 38
(1,031 Views)

You could be correct!  I never expected that math on date time records would operate as anything other than pure cluster element by element math mod range and ignoring any quotients.  

 

I recall getting burned once way back..... before Timestamps existed!  I haven't done much with Datetime records since Timestamps showed up other than Time to Time of Day.vi which I've only used a score or less times in the years since 6.i? 7.0? 7.1?  

 

I guess I just jumped on the bus because you "subtract the Zone offset to get UTC and add the zone offset to get it to me"

 

I think your code may fail with a theoretically possible -4:15 zone.  But of course I can't try it on my phone


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 38
(1,020 Views)

The problem may be how you're testing. If I receive a timestamp from New Delhi (which is the local time in New Delhi followed by the offset "+05:30"), and I run it through the VI which is trying to convert it to local "-07:00" time, that means I subtract 12.5 hours. In the screenshot you posted my code did it correctly (assuming your computer is on Pacfic time).

 

The issue with your version is you are picking up the sign from the 1st %d, but the sign should apply to both hour and minute.

avogadro5_0-1680297150960.png

 

0 Kudos
Message 14 of 38
(1,003 Views)

Well, I have no idea what makes the difference, but here things are now both wrong after your modification.

 

altenbach_1-1680298177284.png

 

 

What time zone are you? Are you absolutely sure your computer automatically switched to DST? (My W11 PC in default settings did not!)

 

altenbach_0-1680298387841.png

 

 

0 Kudos
Message 15 of 38
(991 Views)

I'm in pacific time, but regardless of my computer, yours appears to be on -7 and getting the correct answer. The right answer is not 02:52. The objective is to convert a time from New Delhi to the local time zone. The time you gave it is 14:23 (New Delhi time). That is 01:53 (same day) (Los Angeles time).

 

It may help to try the reverse

 

avogadro5_0-1680300404348.png

 

0 Kudos
Message 16 of 38
(984 Views)

Try the following, note it seems a bit "Rube" in spots and can be improved, but seems to give correct answers. (Note some differences in format specifier, added a ^ and +). Version 2019 attached

 

snip.png

0 Kudos
Message 17 of 38
(905 Views)

Guys, that offset is a relative time so treat it accordingly and don’t try to turn it into a timestamp. Simple turn it into a double as number of seconds and then add/subtract that from the timestamp. LabVIEW is very capable to do arithmetic on timestamps with a relative time! Those arithmetic nodes are quite adaptable.

 

I see McDuff got that idea too. Wonder about that DST handling though. Seems kind of questionable.

 

Officially the timestamp should indicate actual local time and the offset should indicate the current local timezone offset including DST adjustment if applicable. so simply subtracting that from the timestamp converted as UTC should be enough in LabVIEW. A UTC formatted timestamp has a Z instead of the timezone offset.


Although you always end up with a dilemma here. If treated as described above you end up with the correct absolute time as measured by UTC but you may get seemingly off by one errors if your DST time status is not the same as the one observed by the locale in which the timestamp was created. But leaving out DST from the timestamp offset would be even worse as it gets much more complicated to get the original time back.

 

Scientist normally want to know the time in relation to UTC, not if the local people where (s)he looks at the timestamp might have been sleeping at the time the measurement was done somewhere completely elsewhere! 😀 So things need to be related to UTC and conversion can be done to whatever time scale later on, even Klingon if you need to. 😀

Rolf Kalbermatter
My Blog
Message 18 of 38
(888 Views)

Thank you Rolf!

Now, about offset and DST.

 

Let's use NI civil time.  Or, Time in Austin, TX

 

the current Zone is CDT -5:00

on New Year's day 2023 it was CST -6:00.  So, if you have "%z" for any time VALID for current time zone definitions you don't need to worry about DST.  CAVEAT: Time zones definitions are subject to local authorities.  In Fact, no one can predict if Austin, TX will have a "Standard" time in 2030 (there is a movement to adopt permanent DST in the US.)  I imagine that the legislature will consider the implications and, since 5:00pm will come an hour earlier, pass the bill and head off to the bar to begin drinking. 

 

The other missing information about DST is that you are forgetting that transitions occur at local time.   For instance when I adjusted my clock from 2:00AM CDT to 1:00AM CST. Los Angeles was still at 11:00PM PDT only 2 hours difference for the next 3 hours!

 

Sailors in foreign ports,, who want to call their loving mothers at reasonable hours,  learn how to do these calculations. No mother wants to be woken @3:00AM by the telephone operator stating her child's name followed by "Will you accept the charges?"  Thankfully my mother said yes, but I caught an earful and never made that mistake again.

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 19 of 38
(859 Views)

@JÞB wrote:

 

Let's use NI civil time.  Or, Time in Austin, TX

 

the current Zone is CDT -5:00

on New Year's day 2023 it was CST -6:00.  So, if you have "%z" for any time VALID for current time zone definitions you don't need to worry about DST.  CAVEAT: Time zones definitions are subject to local authorities.  In Fact, no one can predict if Austin, TX will have a "Standard" time in 2030 (there is a movement to adopt permanent DST in the US.)  I imagine that the legislature will consider the implications and, since 5:00pm will come an hour earlier, pass the bill and head off to the bar to begin drinking. 

 

The other missing information about DST is that you are forgetting that transitions occur at local time.   For instance when I adjusted my clock from 2:00AM CDT to 1:00AM CST. Los Angeles was still at 11:00PM PDT only 2 hours difference for the next 3 hours!


While indeed nobody can predict the exact timezone rules in the future for any location on earth, most modern OSes have dynamic timezone handling in the form of some database that for pretty much every locale on earth knows the default timezone offset, the times DST is going into effect and out of it, and it has records for every time any of these things changed in that locale. Accordingly when converting UTC to local time and vice versa, these rules are observed based on the actual timestamp, not some arbitrary (current) moment that has absolutely nothing to do with the settings in effect at that time.

 

As long as the OS has active maintenance support, these database files are regularly updated to new rules as they get official. LabVIEW does use OS functions to deal with time, so whatever support the OS offers in that respect is what LabVIEW can offer. Trying to do your own local and time sensitive timezone offset handling is complete insanity.

 

ISO 8601 is very clear. The timestamp should be in local time and the actual time offset to UTC should be added or if it is in UTC a Z should follow it instead of the offset. They made the UTC timestamp specifically different to a timestamp with 00:00 offset from a specific location for a reason. The +00:00 timestamp might actually be right now DST in Island (Reykjavik) for instance.

Rolf Kalbermatter
My Blog
0 Kudos
Message 20 of 38
(839 Views)