Text const to a timestamp

[LED47]

Is there a way to do the following

From text constant and convert that directly into a timestamp that I can use for the X axis for a graph?

[raphschru · Accepted solution]

Hi LED47,

Use "Scan From String" with a timestamp format specifier:

When parsing only a date (without time), LabVIEW adds 1 hour for some reason, so if you want midnight (start of the day), just add a zero for the hours.

Question: Are you sure your input will only contain the date, and not also the time (such as for example "8:45:12.123")?

Parsing a date-only string as a timestamp and using it for the X axis of a graph seems very unusual.

Regards,

Raphaël.

[Bob_Schor · Accepted solution]

Kudos to @raphschru!

Yes, the peculiarity of dealing with TimeStamps in "Human-readable Formats" drove me crazy when I tried to record EEG-like signals in a study a decade or so ago.

Unfortunately, I don't have the code handy to see how I managed to get things working.  I do remember being at an NI Week meeting with my laptop, and noticing my test runs were 1 hour off -- I happened to be at NI Week (so you know it's at least 6-8 years ago), and forgot that Texas is in a different time zone from where the data were acquired, so the "hours" were off by one.

Bob Schor

[LED47]

 Seek and you shall find, thank you very much perfect

[rolfk]

---

@raphschru wrote:

When parsing only a date (without time), LabVIEW adds 1 hour for some reason, so if you want midnight (start of the day), just add a zero for the hours.

---

That one hour simply depends on your time zone. You could argue it's an oversight of the LabVIEW programmers. If there is no time part in a text string it assumes 00:00 but treats that as UTC independent if the format string is indicating UTC conversion or not. But changing that now has quite some implications including potentially breaking about 20 years of existing code at thousands of sites worldwide.

Alternatively you can argue, if a date timestamp (sic) should even have any hourly part. What actually happens is that the internal time format of a timestamp is simply the number of seconds since January 1, 1904 00:00 GMT. There is no timezone in there, it is ALWAYS UTC. So the parsing simply parses the day, month and year part, converts it to that many number of seconds and is done. In the context of UTC, there is no hours, minutes and seconds and subseconds in that timestamp. So it's technically not wrong, but there is this inconsistency of the format string not indicating an UTC timestamp but the conversion still happening as if it was UTC.

And you can't otherwise trick this particular one. Using %^<%m/%d/%Y>T as format string simply causes the function to perform as it already did before, but this time correctly interpreting the string as in UTC time zone. 

[crossrulz]

---

@rolfk wrote:

And you can't otherwise trick this particular one. Using %^<%m/%d/%Y>T as format string simply causes the function to perform as it already did before, but this time correctly interpreting the string as in UTC time zone.

---

Also, you can change the format of the timestamp. Add in that carrot (^) and the timestamp will display in UTC, matching what your string claims to be.

[rolfk]

---

@crossrulz wrote:

---

@rolfk wrote:

And you can't otherwise trick this particular one. Using %^<%m/%d/%Y>T as format string simply causes the function to perform as it already did before, but this time correctly interpreting the string as in UTC time zone.

---

Also, you can change the format of the timestamp. Add in that carrot (^) and the timestamp will display in UTC, matching what your string claims to be.

---

True if it is only about the display. But usually the string constant is converted into a timestamp for some reason and that involves usually other timestamps it relies to and then they both usually need to be in the same time locale.