LabVIEW
How to format string 03-31-23 15:44 into a time stamp
@GerdW wrote:
Hi mshska,
@mshaska wrote:
How do I format 03-31-23 15:44 into a time stamp format?
Use ScanFromString with the right format string. Read the help of that function to learn about all the format codes...
Are we looking at time zone and DST kind of traps as well? Also, if this time stamp is going to cross platform boundaries, we might be talking epoch conversions as well.
@Bob_Schor wrote:
I recently explored this issue. I came to the conclusion that if you really want to record the date and time that was present at the place and time the data were obtained, then you need a true LabVIEW TimeStamp, which records the "actual time". Note that it appears that the OS (Windows, in my case) stores all of the components in the date/time record, including DST, which I realized was important at the recent NI Connect, in Austin, when I looked at a TimeStamp I saved as MM/DD/YYYY HH:MM:SS and tried to make a simple "Navigate a 15 minute sample started at 13:19:22. I had weird problems doing "time arithmetic" (like "move ahead 12 minutes"). I found one of my schemes was "off by an hour" (because I was in CDT, not EDT). So I made a change, and was still having hour shifts (with other data that didn't include MM/DD/YYYY) because I was in a DST = 1 time zone, but Day 0 (1 Jan 1904) is in DST = 0. So, no problem, just include MM/DD/YYYY and "figure out if DST is on". This, it turns out, is a really hairy problem. I'm happy to let Microsoft Windows and LabVIEW TimeStamp take care of this for me ...
Bob Schor
My feeling is that once a timestamp is turned into something that means something to a human, it loses its direct connection to the actual time, and it's very hard to get back to the original timestamp. "Spring forward" not too bad. You have an hour where there were no data. But what about "fall back"? How will you distinguish the "first time" through 2am from the "second time"?
LabVIEW Timestamps (and most other binary timestamps) always are internally in UTC (or if the epoch they use is before around 1960 in GMT but that is technically almost the same if you don’t care about leap seconds and such things). This avoids the discontinuities when switching to and from DST.
There is an ISO standard to represent time in text form that tries to avoid many disambiguaties. It not only tries to determine an order of the elements to avoid mixup of months and days but also adds a timezone offset to the end. This offset specifies the hours and minutes the timestamp is removed from UTC. And it can be instead a Z to indicate zero offset meaning it is an UTC timestamp.
@rolfk wrote:There is an ISO standard to represent time in text form that tries to avoid many disambiguaties. It not only tries to determine an order of the elements to avoid mixup of months and days but also adds a timezone offset to the end. This offset specifies the hours and minutes the timestamp is removed from UTC. And it can be instead a Z to indicate zero offset meaning it is an UTC timestamp.
Search LabVIEW like a graph!
@rolfk wrote:
LabVIEW Timestamps (and most other binary timestamps) always are internally in UTC (or if the epoch they use is before around 1960 in GMT but that is technically almost the same if you don’t care about leap seconds and such things). This avoids the discontinuities when switching to and from DST.
There is an ISO standard to represent time in text form that tries to avoid many disambiguaties. It not only tries to determine an order of the elements to avoid mixup of months and days but also adds a timezone offset to the end. This offset specifies the hours and minutes the timestamp is removed from UTC. And it can be instead a Z to indicate zero offset meaning it is an UTC timestamp.
Granted, but the original text in question does not contain this.
@billko wrote:Granted, but the original text in question does not contain this.
That’’s true, which requires one to make some assumptions. It is pretty safe to assume that such timestamps are in local time, the question of course is in which local time. CMT, EDT, EST or any of the other several dozen possibilities?
And do you really care? Let’s assume you got an isolated weather data set recorded at 13:37 in Tokio/Japan. Do you care if it was actually around midnight at your own location when that measurement was taken? Probably not, so it would be safe to treat the according timestamp simply as is and know that the measurements were taken after noon at the actual location.
But if it is an atmospheric measurement for instance, it may be useful to relate it to other measurements such as sun activity or similar and then you want to have an absolute universal coordinated timestamp. It may still be displayed in local time (the default for a LabVIEW timestamp control) but the underlaying timestamp is stored as UTC. And when converting external formats (ISO or not ISO) to a LabVIEW timestamp you have to consider these things.
