Unable to replicate frations of seconds when reading a timestamp from a binary file

[nyc_(is_out_of_here)]

---

@CJTilley wrote:

---

@nyc_(is_out_of_here) wrote:

Very interesting.

When I use your original timestamp of 8:51:38.139 8/8/2012 to flatten to a text string I come up with 0000 0000 CC48 115A 2395 8106 24DD 2F1B

and when I take that binary hex string and unflatten, I get back the original timestamp.

And, if I use your binary hext string that was in your text file, 0000 0000 CC48 115A 23CD E800 0000 0000 , I also get back the original timestamp.

I have only used the Time Stamp constant to record as-is to a text file.

I agree with you this is very confusing and unexpected.

---

 So you are saying, regardless of which hex string you use, you get the same timestamp back?

---

Yes, doing all of this in LabVIEW.

[crossrulz]

---

@nyc_(is_out_of_here) wrote:

---

@CJTilley wrote:

---

@nyc_(is_out_of_here) wrote:

Very interesting.

When I use your original timestamp of 8:51:38.139 8/8/2012 to flatten to a text string I come up with 0000 0000 CC48 115A 2395 8106 24DD 2F1B

and when I take that binary hex string and unflatten, I get back the original timestamp.

And, if I use your binary hext string that was in your text file, 0000 0000 CC48 115A 23CD E800 0000 0000 , I also get back the original timestamp.

I have only used the Time Stamp constant to record as-is to a text file.

I agree with you this is very confusing and unexpected.

---

 So you are saying, regardless of which hex string you use, you get the same timestamp back?

---

Yes, doing all of this in LabVIEW.

---

Actually, this makes sense.  It is just a matter of how many digits are being displayed.  If your display had more precision, you would see a difference.  You original timestamp should be slightly higher than what nyc created.