LabVIEW
"Scan From String" ignores time zone
Solved!
Well, maybe things are more subtle, but I still only get the correct time with my version (using two different websites):
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:
@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.)
@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.
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.
Well, I have no idea what makes the difference, but here things are now both wrong after your modification.
What time zone are you? Are you absolutely sure your computer automatically switched to DST? (My W11 PC in default settings did not!)
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
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
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. 😀
@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.
