04-02-2023 10:25 AM - edited 04-02-2023 10:26 AM
04-02-2023 12:12 PM
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. 😉
04-02-2023 03:22 PM
There is definitely a bug in the parsing and even formatting of strings for the %z sub-format specifier.
\
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.
04-03-2023 11:18 AM
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:
04-03-2023 11:46 AM
@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.".
04-03-2023 12:38 PM
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?
04-03-2023 12:43 PM
I haven't read this whole thread, but the OP might want to consider the RFC3339 functions in JDP Science Common Tools.
04-03-2023 12:46 PM
@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? 🙂
04-03-2023 12:51 PM
@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.
04-03-2023 12:54 PM
@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.