LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to format string 03-31-23 15:44 into a time stamp

How do I format 03-31-23 15:44 into a time stamp format?

0 Kudos
Message 1 of 28
(1,952 Views)

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

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 28
(1,922 Views)

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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 28
(1,919 Views)

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

Message 4 of 28
(1,882 Views)

@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"?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 28
(1,872 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 28
(1,854 Views)

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


ISO 8601 - Wikipedia

0 Kudos
Message 7 of 28
(1,844 Views)

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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 28
(1,832 Views)

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

 

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 28
(1,823 Views)

See my signature...


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 10 of 28
(1,811 Views)