LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Scan From String" ignores time zone

Solved!
Go to solution

Hi,

 

this one works for my use cases:

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 21 of 38
(1,139 Views)

Yes, I was probably confused about the direction and purpose of all this. So we get some log with a timestamp and offset from somewhere across the globe and would like to know what our local time was when that event occurred.

 

It is still not clear to me why scanning a time string that includes an explicit offset does not translate into our local time the way the OP expected. Apparently, the offset (which is a true number, not linked to any specific time zone or time zone rule!) gets simply ignored.

 

Oh well.... obviously, I am still confused. 😉

 

0 Kudos
Message 22 of 38
(1,124 Views)
Solution
Accepted by avogadro5

There is definitely a bug in the parsing and even formatting of strings for the %z sub-format specifier.

 

Timestamp Conversion.png\

The parsing with the %z format specifier correctly consumes the time offset but does not do anything with it at all. That it consumes the time offset is shown by the fact that the remaining string only contains "Test".

 

But formatting also doesn't quite work as intended for positive offsets as it misses the plus sign. Without that sign there is no way to know where the time part of the timestamp stops and where the offset starts. The sign should always be present for %z. But I also tried to add the + sign to the %+z specifier. This works for integer values to always print the sign even for a positive integer. But with that it even runs into an error and does not convert anything.

 

In my opinion there are at least two bugs in the %z format specifier.

 

- When formatting, it does not include a + sign with it, (and doesn't allow to force it with the + format specifier). Also there seems no way to tell it to only format %H:%M, it insists on formatting %H:%M:%S

 

- And when scanning, it processes and consumes the offset part but does nothing at all with it.

Rolf Kalbermatter
My Blog
Message 23 of 38
(1,099 Views)

Lots of interesting discussions on workarounds but I'm pretty sure the actual answer is for "why does %z not do anything on scan from string?" is "LabVIEW bug."

 

Some cautions:

  • I've seen a few solutions that use a "%d" to capture the sign on the hours: this sign also needs to apply to the minutes.
  • Some solutions, including mine, rely on the "date time rec" cluster supporting negative and/or rolled over fields. This appears to work, but seems undocumented, and in fact the documentation on these nodes suggests it won't work. So, it is probably safer to apply an offset in seconds.
  • This way of specifying time zones does not have any information about DST, so it's unavoidable to have some "off by one" weirdness when DST switches back and forth.
0 Kudos
Message 24 of 38
(1,056 Views)

@avogadro5 wrote:

Some cautions:

  • I've seen a few solutions that use a "%d" to capture the sign on the hours: this sign also needs to apply to the minutes.

Good catch about the minutes; would need to modify my solution to work.

 


@avogadro5 wrote:

Lots of interesting discussions on workarounds but I'm pretty sure the actual answer is for "why does %z not do anything on scan from string?" is "LabVIEW bug."


Not sure about this. According to the help...

%T specifies absolute time. Any information you include with the < and > brackets indicates how you want to format the absolute time. This format, including the punctuation, changes based on the regional settings of the computer. The time changes based on the configured time zone for the computer.

 

As I understand the help, Absolute Time is UTC which has no offset, thus any added offset is ignored. Although now I am unclear what the "^" does, as the help says "Add ^ to format the time in Universal Time.".

0 Kudos
Message 25 of 38
(1,046 Views)

Put it this way: we're pretty deep in this thread and no one has produced an example of %z doing anything at all on scan from string other than capturing part of the input. So why is it even an option?

0 Kudos
Message 26 of 38
(1,034 Views)

I haven't read this whole thread, but the OP might want to consider the RFC3339 functions in JDP Science Common Tools.  

 

2023-04-03 18_37_06-Context Help.png

0 Kudos
Message 27 of 38
(1,029 Views)

@avogadro5 wrote:

Put it this way: we're pretty deep in this thread and no one has produced an example of %z doing anything at all on scan from string other than capturing part of the input. So why is it even an option?


Maybe it is meant to be used only for Format Into String??

 

From the length of this thread, it appears formatting into a timestamp it is not a simple task even for multiple knights of NI, what makes you think NI solved the problem? 🙂

0 Kudos
Message 28 of 38
(1,020 Views)

@mcduff wrote:

 

As I understand the help, Absolute Time is UTC which has no offset, thus any added offset is ignored. Although now I am unclear what the "^" does, as the help says "Add ^ to format the time in Universal Time.".

"Absolute Time" isn't Universal Time, it's a specific time, as opposed to a Relative Time.  Eg: "March 30 and noon" as opposed to "two days".  An Absolute Time can be Local or Universal.

Message 29 of 38
(1,016 Views)

@avogadro5 wrote:
  • This way of specifying time zones does not have any information about DST, so it's unavoidable to have some "off by one" weirdness when DST switches back and forth.

The Offset doesn't specify the Timezone, just the Time Offset, including any Daylight Savings Time.

0 Kudos
Message 30 of 38
(1,011 Views)