LabVIEW
"Scan From String" ignores time zone
Solved!
I receive timestamp strings that come with timezone offsets, and I want to convert them into LabVIEW timestamps in a consistent manner such that they can be sorted chronologically.
They look like "2023-03-08T19:42:41.000+00:00" or "2023-03-08T12:52:31.000-08:00," so I have to account for the time zone offset at the end. The way to handle this in LabVIEW appears to be with the "%z" format specifier. When I use this specifier on the "Format Date/Time String" or "Format Into String" nodes, my local time zone offset is correctly appended. But when I use the "Scan From String" node with the same format specifier, the offset appears to be ignored:
I would expect the output values to be different when the offsets are different, but they are not. Is there some step I'm missing here?
To increase the chance of anyone helping, I recommend to attach your VI (LabVIEW 2020 or earlier preferred).
Nobody here want to waste time recreating a VI from a picture just to test a few things. Thanks!
@avogadro5 wrote:
I attached a LV 2021 VI version of the example I posted above.
Well, this has to wait then because my current laptop only has LabVIEW 2020. 😞
My best guess is that scan from string uses a simplified format.
I think you could simplify your subVI as follows. Timezones are quantized in minutes (there exist some 30 and 45 minute offsets, e.g. New Delhi has +5:30).
Note that your VI is incorrect if the minute offset is nonzero, so be careful! (not fully tested, so no guarantees!):
I'm only including seconds in the offset because LabVIEW's %z specifier does.
I don't understand your suggestion for my VI. I tried an experiment with New Delhi time and my VI seemed to work when I Googled New Delhi time. Shouldn't the minutes be inverted if the hours are?
@avogadro5 wrote:
I receive timestamp strings that come with timezone offsets, and I want to convert them into LabVIEW timestamps in a consistent manner such that they can be sorted chronologically.
They look like "2023-03-08T19:42:41.000+00:00" or "2023-03-08T12:52:31.000-08:00," so I have to account for the time zone offset at the end. The way to handle this in LabVIEW appears to be with the "%z" format specifier. When I use this specifier on the "Format Date/Time String" or "Format Into String" nodes, my local time zone offset is correctly appended. But when I use the "Scan From String" node with the same format specifier, the offset appears to be ignored:
I would expect the output values to be different when the offsets are different, but they are not. Is there some step I'm missing here?
A few questions:
- Have you tried replacing the <>T with <>t in the scan from string format specifier?
- What exactly are the timestamp indicator's display formats?
And yes, CA meant to subtract 5 hours and 30 minutes instead of 4:30. Must have been a Sr. Moment. He will certainly catch up in an hour. It really does not matter if you add or subtract 30 or 0 to n mod 60... but you have to get it right on the 15" and 45" offsets. Then you need to carry minutes crossing 0/60 into the hours and hours crossing 0/24 into days DOM, DOW, JULIAN etc... a very bug prone method. Better to just convert everything to DBL, as seconds since epoch, then back to Timestamp. The coercion errors will be in the dirt by several orders of magnitude for mSec resolution.
Every Time Lord knows that their Sonic Screwdriver needs a double.
@avogadro5 wrote:
I don't understand your suggestion for my VI.
That's why I said "no guarantees". Yes, I thought that the minutes should be inverted too, but in my casual testing it gave the wrong result. <Shrug>
I'll have another stab once I am on a computer with LabVIEW. 😄
