Write timestamp to string and read it again ..

[ravyh]

Hello, 

can anybody please throw some light on the "under the hood" of this simple snippet?

If you run the vi repeatedly you can observe that the boolean indicator is sometimes true sometimes false depending on the timestamp from Get Date/Time in Seconds vi. Can you tell what exactly it depends on?

I'd expect that the 'Scan from String' and 'Format Date/Time String' vis would work in a 'inverse' manner one to the other but it doesn't seems so. I see that the difference between the timestamps is of value of the LSB of the time stamp data type - it makes me think of a different way in rounding the value somewhere, but where and why? 

[RavensFan]

At the end of the day, you are comparing two timestamps with each other and that is pretty much the same as comparing two floating point numbers.  You really can't compare two floating points and expect equality.  For one, you are taking through to a string and back.  The conversion probably causes just enough change in the value that they aren't exactly equal even though it looks like they are two 19 decimal places.

[ravyh]

RavensFan, thank you for your input. 

Is this really the case of comparing TWO floats? I understand that comparing floating point numbers is tricky: if we say x = 0.1 the physical data stored will not really say that x equals 0.1 which then makes comparing x to other numbers act 'strange'. But the situation described above is more like saying x = 0.1 and then asking if x == x ? which should give true no matter how imprecisely x was stored. 

According to this document:https://www.ni.com/en/support/documentation/supplemental/08/labview-timestamp-overview.html  the time stamp data type in labview is a 128bit fixed point number. The conversion to/from string of fixed point number should not loose in precision, in my opinion.. so what am i missing?

[crossrulz]

---

ravyh wrote: so what am i missing?

---

The conversion To/From string adds error whenever decimal places are involved.  It is just a limitation of using bits to define decimal places.  Or maybe if you showed 100 decimal places it would be close enough for you (1/2^64 = 5.4210108624275221700372640043497e-20, as accurate as the Windows calculation shows, so good luck figuring out how many fractional seconds places you need in your string)?

[ravyh]

The conversion To/From string adds error whenever decimal places are involved.  It is just a limitation of using bits to define decimal places.  

---

Could you please elaborate on this a bit more? 

I (believe that I) understand the limitations of representing decimal places but i think my situation here is one step further this limitation: im not asking the compiler to create a fractional number which cannot be exactly stored in bits - i receive a well representable number from the get date/time vi or don't i?

[crossrulz · Accepted solution]

---

ravyh wrote: im not asking the compiler to create a fractional number which cannot be exactly stored in bits - i receive a well representable number from the get date/time vi or don't i?

---

With only 19 decimal places, you cannot accurately go between a 64 bit number (the fractional seconds) and the string without losing accuracy.  As I stated before, you need to have enough digits to accurately represent 1/(2^64).  Unless you can do that, you will never have the conversion to string and back be EXACTLY the same.  For 99.9999999999999999999999999999999% of the time, it will be close enough.  So instead of equals, you really should be checking if the difference is less than an acceptable value.

[ravyh]

Thank you!

My mistake was that i was doing the calculations with 2^64 and not 1/2^64

[parthabe]

---

@crossrulz wrote:

So instead of equals, you really should be checking if the difference is less than an acceptable value.

---

Exactly! 🙂

Below is the link to the post which I coded just yesterday.

https://forums.ni.com/t5/LabVIEW/how-to-generate-excel-report-daily-using-write-to-spread-sheet/m-p/...