From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TimeStamp to Text = Insanity

Solved!
Go to solution

LV2013.

 

I need to take a TIMESTAMP and export it to text (suitable for a spreadsheet cell), and then import that text back in, and get a BIT-PERFECT replica of the original TimeStamp.

 

For a DBL, I do this using FORMAT INTO STRING, with a format of "%#_17f".

That gets me up to 17 digits, hiding trailing zeroes, and I haven't seen a number that won't come back bit-perfect.

 

But for a TIMESTAMP, it's different.

I can output 17 digits, or TWO HUNDRED AND FORTY digits, and it still doesn't work.

 

240.PNG

If I had known this going in, I could have rounded the timestamp to .xxx and been OK.  But I have data files that I need to apply this to and they have "current times" in them as timestamps.

 

1... It's absurd that it will spit out 240 digits.  It will break at 255 or less, I think, but still, 240 is ridiculous pretentiousness.

2... Apparently, the SCAN FROM STRING will quit at 17 digits and call it done.

 

But even the 17 digits is not enough to result in an exact match.

 

Any ideas how to fix this?

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 25
(5,206 Views)

Maybe the information in this thread will help?

0 Kudos
Message 2 of 25
(5,177 Views)

LabVIEW's TimeStamp format is weird.  It is saved as a 128-bit quantity.  The top 64 bits can be interpreted as the number of seconds since (I forget the Magic t0), and the low 64 bits represent fractions of a second.  Needless to say, representing such a fraction exactly in decimals could be messy!

 

If it is critical that you be able to save the LabVIEW TimeStamp in Excel and get it back exactly as it was in LabVIEW, the only way I can think to do this is to use the exact 128-bit representation, which I'd do as an array of I64's (two of them, naturally).  Actually, you might do better with U64's, as you won't have to deal with negative numbers in the "fraction" part.  Of course, these numbers are pretty meaningless to someone reading a column in Excel (can you figure out that 3599677600 is sometime after 5pm today?), but you can save a text string of "24 Jan 2018 5:20 pm" for the poor Human reader ...

 

Bob Schor

 

P.S. -- if you really want to drive yourself nuts, try converting a LabVIEW TimeStamp (number) into an Excel Date/Time (different representation of time, different TimeZero) ...

Message 3 of 25
(5,171 Views)

No, that post deals with endian-ness and memory layout, and I don't use or care about that in this case.

 

For the record, LV 2017 has the same bug (feature?)

 

Attached is the 2017 VI.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 4 of 25
(5,167 Views)

Thanks, Bob, but the spreadsheet version has to be human-readable and editable.  It's just that if they DON'T change it, I want it to come back as UNCHANGED.

 

Off to Tech Sopport it goes.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 25
(5,165 Views)

This might be the equivalent of writing a Float into Excel and detecting if it has changed.  Once you change to text (which is all we poor humans can read), you have a problem, particularly if you need to know if the value has changed or not (think about the float approximation of 0.1 ...).  It's very messy.

 

Bob Schor

0 Kudos
Message 6 of 25
(5,155 Views)

But I can do it correctly with a DBL- I need 17 digits to do it but it works. 

 

If if it has a finite representation in binary, it should have a finite representation in text and be convertible, it seems to me.

 

i understand that 0.1 is not a round number in 754, but I can still convert it to text and back without error.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 25
(5,145 Views)

@CoastalMaineBird wrote:

Thanks, Bob, but the spreadsheet version has to be human-readable and editable.  It's just that if they DON'T change it, I want it to come back as UNCHANGED.

 

Off to Tech Sopport it goes.


What are you doing that requires 9 decimal points of precision?  It comes back matching the 8.  It appears you're using Windows so the jitter alone will push you beyond that level of precision.

0 Kudos
Message 8 of 25
(5,116 Views)
Solution
Accepted by CoastalMaineBird

Hmm, I am not sure this is what you want? (just after wake up, early morning 🙂 )...

LV TimeStamp Bug.png

 

Message 9 of 25
(5,098 Views)

What are you doing that requires 9 decimal points of precision?

 

Comparing a large cluster, of which a TimeStamp is but one piece, which I exported to text, to another cluster, which I just imported from text, in one EQUALS operation.

 

Rather than unbundle the thing and comparing individual pieces, I want to test if this cluster = that cluster and get an honest answer.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 25
(5,066 Views)