LabVIEW time stamp algorithm for use in other programs

[QuantumPenguin]

Hi all,

Possibly not the correct place to post this, as this is more of a LabVIEW technical question -- but here goes:

My data is acquired in LabVIEW, but I analyze it in other software packages, I need to convert my LabVIEW time stamps to human read able i.e. from 3628424925.79337740 to yyyy/mm/dd.

In LabVIEW, easy! But to do in something like Mathematica for example, I need to know the algorithm LabVIEW uses to generate time stamps in the format. Of course I could generate this in LabVIEW then export, but that is really a last resort.

If anyone knows the algorithm used, or where I can find it that would be great, as I can then code in whatever I need to do this in.

Thanks

[billko · Accepted solution]

---

@QuantumPenguin wrote:

Hi all,

Possibly not the correct place to post this, as this is more of a LabVIEW technical question -- but here goes:

My data is acquired in LabVIEW, but I analyze it in other software packages, I need to convert my LabVIEW time stamps to human read able i.e. from 3628424925.79337740 to yyyy/mm/dd.

In LabVIEW, easy! But to do in something like Mathematica for example, I need to know the algorithm LabVIEW uses to generate time stamps in the format. Of course I could generate this in LabVIEW then export, but that is really a last resort.

If anyone knows the algorithm used, or where I can find it that would be great, as I can then code in whatever I need to do this in.

Thanks

---

There's no real algorithm.  Any timestamp represented in that manner is the number of seconds since [INSERT THE APPROPRIATE EPOCH TIME HERE].  In LabVIEW, it's the number of seconds since LabVIEW epoch time, or Jan 1, 1904.  Now that you know what that number is, you should be able to go back and forth between different epoch times with ease.

[pauldavey]

I would add that it is that simple only when the timestamp is in the UTC timezone. For other timezones you need to account for daylight savings, so it is best to start in UTC and then convert it to the relevant timezone (if necessary).

[billko]

---

@pauldavey wrote:

I would add that it is that simple only when the timestamp is in the UTC timezone. For other timezones you need to account for daylight savings, so it is best to start in UTC and then convert it to the relevant timezone (if necessary).

---

I'm pretty sure that all timestamps are in UTC otherwise they wouldn't be true timestamps.  The only "conversion" is to display it in a manner appropriate to your timezone.

[Bob_Schor]

---

@billko wrote:

---

@pauldavey wrote:

I would add that it is that simple only when the timestamp is in the UTC timezone. For other timezones you need to account for daylight savings, so it is best to start in UTC and then convert it to the relevant timezone (if necessary).

---

I'm pretty sure that all timestamps are in UTC otherwise they wouldn't be true timestamps.  The only "conversion" is to display it in a manner appropriate to your timezone.

---

And I just confirmed that by (at almost midnight, EST, Jan 6, 2019), I converted the Current Time into a Dbl, then to an I64, divided by 84600 (to get days) then 365.25 (to get years.  I also divided the remainder from the first division (that got days) by 3600 to get hours.  I got 115.017 years, and 115+1904 = 2019 (correct!).  0.017 * 365 = 6.2 (days) and Jan 1 + 6 = Jan 7, the correct "day" for UTC, since EST = UTC - 5 hours.  Finally, Hours was 4+, a Hours was 4 and change, and 11-something PM EST = 4-something AM UTC (again, adding in the additional 5 hours).  So the LabVIEW Timestamp Value is, indeed, a UTC time, which LabVIEW nicely "expresses" for us (in a Windows PC) according to the Time Zone setting in effect on the PC.

Whew!

Bob Schor