Fractional seconds lost during timestamp to DBL conversion?

[shuttlefan]

I need to get a labview timestamp to the form of Sec + nanosec from epoch

My understanding is that when you use the DBL float conversion, it outputs a number that is in SECONDS.

Seems that this does not account for the fractional portion?

So to get the fractional part, I have extract the fractional SECOND from the original timestamp?

Am I doing this correctly?

[mcduff]

I can see the fractional part in LabVIEW 2021. See below

[shuttlefan]

Interesting....I was looking at the probe and indicator and it all just showed integer value.  No decimals.

I will try this out.

[JÞB]

---

@shuttlefan wrote:

I need to get a labview timestamp to the form of Sec + nanosec from epoch

My understanding is that when you use the DBL float conversion, it outputs a number that is in SECONDS.

Seems that this does not account for the fractional portion?

So to get the fractional part, I have extract the fractional SECOND from the original timestamp?

Am I doing this correctly?

---

Uhmmmm....

~~~~Oh magic 8-Ball! Did Shuttlefan really Coerce the dbl to an integer datatype and expect a floating point number?~~~~

Yup.

The timestamp to datatype will return seconds since epoch-as a floating point number (including any fraction that fits into those @15 digits of precision)

Your probe is likely set to 6 significant digits and there are > 3.7e+9 seconds since epoch.  That only leaves 6 digits leftover after the decimal. Nanosec resolution cannot happen in a DBL. The Timestamp does hold Seconds as I64 and another 64bit int for the fractional portion of seconds so would have greater precision. I'm not sure how that lower 64bits really works. (I think it is U32/U32 but don't quote me)  Grabbing the fractional seconds from the Datetime record would be a valid means for sub-microsecond resolution but, will be limited to the resolution of the high resolution timer HARDWARE in your machine.  nSec resolution in a non-deterministic OS is simply a crazy idea without scientific worth (you just can't get a value above the noise floor)

[shuttlefan]

I was looking at the probe (not shown) upstream of the coercion and it only showed integer.  

Unless the probe is whatever the resulting storage is.

If so, that's a subtlety I didn't know about probes.

I'll run it both ways to see how it works.

[mcduff]

---

@shuttlefan wrote:

Interesting....I was looking at the probe and indicator and it all just showed integer value.  No decimals.

I will try this out.

---

If you use the Quotient and Remainder, you should be able to get your integer and fractional parts; then convert to correct units(nanoseconds) and datatype.

[JÞB]

---

@mcduff wrote:

---

@shuttlefan wrote:

Interesting....I was looking at the probe and indicator and it all just showed integer value.  No decimals.

I will try this out.

---

If you use the Quotient and Remainder, you should be able to get your integer and fractional parts; then convert to correct units(nanoseconds) and datatype.

---

See edits in my previous reply.   The Remainder mod1 won't have e-9 precision as the OP asked for (roughly e-6 is the 15 sig digit total for dbl considering the e+9 needed for whole seconds)

[rolfk]

The 1e-9 resolution is anyhow doomed. The underlaying time functions in Windows have a 100 ns resolution (the value is an int64 that indicates the number of 100 ns intervals since Jan 1, 1601 GMT).

And even that is not guaranteed to monotonically increment by 1 but can skip counts as the necessary interrupt won’t occur exactly every 100 ns but can and will skip some intervals regularly.