LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Scan From String" ignores time zone

Solved!
Go to solution

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:

avogadro5_0-1680220512510.png

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?

 

0 Kudos
Message 1 of 38
(1,418 Views)

%z -> %Z

0 Kudos
Message 2 of 38
(1,351 Views)

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!

0 Kudos
Message 3 of 38
(1,348 Views)

The "%Z" appears to give a string description of the time zone. I need to parse an offset in the form of +/-HH:MM, so I don't think that will work.

 

I attached a LV 2021 VI version of the example I posted above.

0 Kudos
Message 4 of 38
(1,332 Views)

@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. 😞

0 Kudos
Message 5 of 38
(1,328 Views)

I attached the example saved for LV 2016 and my hacky solution that appears to work well enough for my non-critical use.

Download All
0 Kudos
Message 6 of 38
(1,310 Views)

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!):

 

altenbach_1-1680286208638.png

 

altenbach_2-1680287000023.png

 

 

 

 

 

Message 7 of 38
(1,295 Views)

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_1-1680289379998.png

 

 

0 Kudos
Message 8 of 38
(1,279 Views)

@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:

avogadro5_0-1680220512510.png

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.


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

@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. 😄

0 Kudos
Message 10 of 38
(1,262 Views)