LabVIEW
"Scan From String" ignores time zone
Solved!
@drjdpowell wrote:
@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.
In the help, NI seems to link UTC to Absolute time, at least in my head, but that is usually wrong.
@mcduff wrote:
In the help, NI seems to link UTC to Absolute time, at least in my head, but that is usually wrong.
The LabVIEW Timestamp is always UTC (though confusingly displayed in local time by default. But I think those examples are actually wrong.
Absolute time is a date/time value, using an epoch (the LabVIEW epoch is Jan 1, 1904 GMT, the Unix epoch is usually Jan 1, 1970 UTC. The timestamp is in fact also a relative time towards that epoch.
Relative time is simply a floating point or integer value indicating the number of seconds to an arbitrary base (the beginning of your measurement, or whatever).
The important thing is that an Absolute time is simply a relative time that is always related to an epoch which is a specific moment in some specific calendar. And as we have seen it can be a different epoch depending on the environment. But these epochs are usually always in UTC (or GMT, since UTC officially only exists since Jan 1, 1960).
So yes a LabVIEW timestamp is internally always in UTC/GMT since it is related to the Jan 1, 1904 GMT epoch. But what the timestamp shows is by default local time. And that is not just for some arbitrary reason. People would be generally very upset if a timestamp indicator would show a different time than what their local computer clock shows, and all OSes by default are configured to show local time. But if you set your Windows system to be in UTC, then yes LabVIEW will simply show that too, as that is then the local time of your computer.
So Absolute time is not equal to UTC, it is an absolute time with date and time. Relative time is neither local time but simply a time difference to an arbitrary start time.
What the Timestamp display shows is either UTC or local time, depending on its configuration but the underlying value in the wire is always "number of seconds since Jan 1, 1904 GMT". Think of it as pretty much the same as how a numeric control can be configured to display an integer value as either decimal, hexadecimal, octal or binary. The control shows a different "number" but the underlying numeric value stays exactly the same.
@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.".
I would say that if the format is %^<....%z> it should actually format a "Z" in there. It's arguable of course what standard LabVIEW should follow but ISO 8601/RFC3339 seems a good one nowadays.
For %<.....%z> it should always include the sign to the offset and it would be useful to support some size specifier such as 1 for only hours, 2 for hours:minutes and nothing or 3 for hours:minutes:seconds. It at least should support the plus + sign as extra format specifier to force a + for positive offsets.
For scanning it should simply properly scan de offset (which it seems to do) and use that value to adjust the timestamp. And it should support a Z in there to indicate that the timestamp is actually UTC.
Off topic, but another time pet-peeve/problem.
Start LabVIEW, run snippet, while VI is running change the Time Zone. The current time is not updated. 😞
LabVIEW initializes the timezone settings (and other locale settings) when starting up. There would be a Windows message (WM_SETTINGCHANGE) that tells all applications that some locale settings have changed but LabVIEW does not fully process that.
@mcduff wrote:
@rolfk wrote:
LabVIEW initializes the timezone settings (and other locale settings) when starting up. There would be a Windows message (WM_SETTINGCHANGE) that tells all applications that some locale settings have changed but LabVIEW does not fully process that.
Yes. I made a callback for that function so I know. Staff travel where I work and sometimes switch time zones in the middle of an acquisition, needed a solution to correctly add a timestamp to the filename. Frustrating.
Automatic update could be just as annoying! Imagine you have a slow measurement of once a second or less and you use a timestamp for each measurement. User changes timezone and bam you suddenly have a jump back in time for a few hours. Frustrating too!
