Overflow in "To Time Stamp" function

[BJenso]

I have been looking into our systems to check how different time stamps will hold in the future. I discovered that LabVIEW will run into problem first. Our LabVIEW application is reading an UNIX timestamp (U32 holding seconds since 1970) from an Embedded system and this is converted to LabVIEW timestamp (seconds since 1904) using the library function "To Time Stamp". My experience is that this function has internal limitations. When the input value to this function exceed the maximum value of U32, an overflow will occur and the time starts from 1904. This happens no matter what type of input is used for the "To Time Stamp" function, U64, DBL etc. This overflow will occur in 2039. UNIX time stamp has limitation too. If using S32 will have overflow in 2038 and a U32 will not experience overflow until 2106.

[cordm]

Interesting observation. The maximum u32 value as seconds corresponds to 07:28:15 06.02.2040 when converted to a LabVIEW timestamp. 

1904 to 2040 is 136, which matches with the number of years in the u32 unix epoch 1970 to 2106.

It looks like the wrap is occuring when converting from Unix to LabVIEW epoch. Try expanding the embedded timestamp to double or i64 before doing that.

[Bob_Schor]

A TimeStamp is a "special" LabVIEW quantity, represented by a U128 value that can be considered as an array of 2 U64 quantities.  I played around with trying to "understand" LabVIEW timestamps -- I think documentation exists somewhere, but I can't locate it at the moment.

If you coerce a TimeStamp into an Array of U64, you'll see there is a "High Integer" and a "Low Integer".  The High integer is the number of seconds since Time 0 UTC (this is mostly from my increasingly-faulty memory, so some details might not be quite correct).  If you look at a current timestamp value, this should be a positive quantity, since we are more than a century beyond Jan 1, 1904.  What about a TimeStamp corresponding to 1900?  I think this is simply represented by a "negative" value (i.e. the high bits of the U64 will be set instead of 0's).

What about the second U64?  That represents fractions of a second (so 10:23:45.243795) using the top three bytes (with the other 5 being zero).  I'm not sure where it is, say, a "microsecond counter" (or millisecond, or some fixed interval) but a little experimentation  should reveal the answer.

I know I've seen on the Forums a better description of TimeStamps -- "Seek and Ye Shall Find".

Bob Schor

[altenbach]

So the problem is not with LabVIEW, but with the ancient UNIX system. Most likely you can just take that raw 32bit integer and decide if a wrap needs to be corrected to bring the time into a reasonable year. If LabVIEW needs to base all information from 32 bits, there will be ambiguities that are multiples of ~132 years.

[cordm]

In case you are using Get Date Time String, that seems to be using a u32 for whole seconds internally because it does not work past that date.

Get Date/Time String does not work for dates beyond 2/5/2040, bug number 166351 (https://www.ni.com/en/support/documentation/bugs/21/labview-2021-known-issues.html)

 

[Andrey_Dmitriev]

---

@BJenso wrote:

using S32 will have overflow in 2038

---

Exactly the year I plan to retire! Good point — the problem doesn’t exist for me at all.

Sorry for going off topic.

[rolfk]

A little nitpick. Technically, the LabVIEW timestamp is defined as 2 64-bit integers, the most significant is an int64 which is the number of seconds since Jan 1, 1904. The remaining is an uInt64 and specifies the fractional part of a second.

The fractional part is however only using the first 32-bits and leaves the lower significant 32-bits always as 0. Under Windows the theoretical resolution is only 100ns, so only really using about 25 bits of that fractional seconds value, that's the resolution of the Windows FILETIME. Practically it is of course quite a bit larger as the system clock is not incremented continuously every 100 ns. Linux has a system clock returning ns, so really using 30 bits of that fractional value, but of course the increment is quite a bit larger too.

Pure timestamp arithmetic should work fine since LabVIEW does proper 64-bit arithmetic and even correctly accounts for carry over if the fractional seconds overflow or underflow.

A LabVIEW timestamp also can contain times before 1904 when the first 64-bit value is negative, practically I wouldn't trust that every function will work with that. Notable problems are likely in some of the legacy Timestamp to string and similar conversions. However at least on Windows the timestamp control happily will display times before 1904 and past 2040 without any problems and Format into String and Scan from String work properly with that too.

For dates before 1600 however it will not work. This is notable since on Windows the epoch is actually Jan 1, 1601 so LabVIEW does not seem to fully rely on Windows functions for this conversion but choose the lower limit of Jan 1, 1600 for a timestamp for some reason. It's also not very useful to go further since there was a discontinuation in 1582 when the calendar jumped several days to move from Julian to Gregorian calendar. But I'm not sure how non-Windows platforms will deal with dates before 1904. LabVIEW even seems to correctly account for February 29, 1600, which Windows conveniently tried to avoid by setting it's epoch to 1601.

[alexderjuengere]

---

@Bob_Schor wrote:

A TimeStamp is a "special" LabVIEW quantity, represented by a U128 value that can be considered as an array of 2 U64 quantities. 

[...]

I know I've seen on the Forums a better description of TimeStamps -- "Seek and Ye Shall Find".

---

a good soul put together this knowledge article 

https://www.ni.com/en/support/documentation/supplemental/08/labview-timestamp-overview.html?srsltid=...

[rolfk]

---

@alexderjuengere wrote:

---

@Bob_Schor wrote:

A TimeStamp is a "special" LabVIEW quantity, represented by a U128 value that can be considered as an array of 2 U64 quantities. 

[...]

I know I've seen on the Forums a better description of TimeStamps -- "Seek and Ye Shall Find".

---

a good soul put together this knowledge article 

https://www.ni.com/en/support/documentation/supplemental/08/labview-timestamp-overview.html?srsltid=...

---

And again another detail for the low level interested. The definition in that article may seem to indicate that the seconds part preceds the fractional part. However, this is for the LabVIEW Big Endian format, which defines Most significant Byte/Word/Long/Quad first. But the real definition in as far as C code goes is actually as follows:

struct {
#if NI_BIG_ENDIAN
    int64_t seconds;
    uint64_t fraction;
#else
    uint64_t fraction;
    int64_t seconds;
} LVTimestamp;

Since there is currently no Big Endian platform for LabVIEW anymore (the only ever released ones were MacOS 68K, MacOS PPC, Sun Sparc, HP Unix, and VxWorks, other never released ones were SGI, IBM AIX, Linux PPC, Linux MIPS), the definition in the knowledge article is slightly misleading.