<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">


Absolute Time in LabVIEW

I’m sure that most developers have read Falsehoods Programmers Believe About Time. Most, if not all, of these ideas can ALSO happen in LabVIEW; things can also be complicated when absolute time data must be used on multiple machines that are not in the same time zone. Have you ever logged data on a computer in the central time zone, loaded it on a computer in the eastern time zone, and then found that the data was an hour off? Have you ever saved data during daylight savings time (fall backwards) and had a weird graph with one hour? This blog post seeks to provide solutions for those problems and describe how LabVIEW handles time. Example code included!

Absolute time in LabVIEW can be expressed as a time stamp or as a Double Precision Floating Point number, each expressing the number of seconds that have passed since epoch (01/01/1904 00:00:00.00 UTC). Although there are some other caveats (not the same epoch or precision as Unix and ignores leap seconds), it generally means that ‘now’ - epoch = absolute time. LabVIEW timestamps are ALWAYS stored as UTC and then automatically modified for the computer’s timestamp. When converting timestamps into doubles, some precision is lost, but they're ‘about’ the same.

VI snippet showing conversion from time stamp to double


  1. Drag and drop VI snippet above into an empty VI
  2. Run the VI to print the current time
  3. Change the time zone
  4. Restart labVIEW
  5. Run example again
  6. Observe the difference in time

Because LabVIEW automatically modifies timestamps for display, it means that if you capture data in Central time zone (-6) and display it on a computer configured for Eastern time zone (-5), your absolute time will be off by an hour. To solve this problem, you must explicitly offset the time before displaying it.

To Convert a timestamp, you need the following:

  • Time stamp (timestamp/double)
  • UTC Offset/Time zone (double)

Convert to source time zone:UTC + [((time_zone_source - time_zone_destination)*3600)] = Source Timestamp

For example:

  • [s_time] Source Time - 14:25:42.045 01/06/17 or 3579189942.045315
  • [s_time] Source Time (UTC) - 20:25:42.045
  • [s_tz] Source time zone - central (-6) [data logged here]
  • [d_tz] Destination time zone - eastern (-5) [data being displayed here]
  • [d_time] Destination time

To display the time recorded on a computer in central time, on a computer configured in eastern time:

d_time=[s_time + ((d_tz - s_tz)*3600)]

This calculation can be done with a time stamp control or a double precision floating point number to achieve the desired effect of displaying data in the correct time zone. The only caveat is that because we explicitly offset the time, if we want to pass it on or modify it, we must convert it BACK to the correct time to be able to use it.

The example code (found here) show the following situations:

  • How to convert a timestamp for display purposes in the source time zone
  • How graph data looks during fall backward or spring forward
  • How to search an array of timestamps

In general, the best way to save your log data that must be viewed in multiple timezones is to include absolute time information in your configuration like the following scenarios:

  • If the timezone is static, just information regarding whether DST is observed and the UTC offset for the timezone
  • If the timezone is changing (and timezone information is important), when the timezone changes, record the UTC time of when that change occurred, the new timezone as well as if DST is observed in that timezone

Often absolute time corrected for timezone is unnecessary unless trying to correlate/compare collected data with localized events.



Recent Posts:

The Absolute Necessity of Goals
Publish Date 15 Aug 2017 Cameron BashamAntonio Alexander

The Biology of Goals

Nyquist Rate and Antialiasing Filter Explained
Publish Date 15 Aug 2017 Jason ThaiAntonio Alexander

In mud pulse telemetry, we use a sync signal for synchronization. A commonly used [..]

Good Firmware Programming: Quantitative vs Qualitative
Publish Date 15 Aug 2017 Yifang YangAntonio Alexander

Write Software for others as you wish they would write for you.

Simulations and Data Driven Approach for Improved Code Deployment
Publish Date 15 Aug 2017 Saravanan PandiyanAntonio Alexander

  Introduction At Erdos Miller, we are firm believers in making data-driven [..]

Wireframe, Mockups, and Prototypes
Publish Date 15 Aug 2017 Ashton ScaliseAntonio Alexander

Before implementing a new feature in an application, it is common practice to create [..]

Simple Practice of Time Management
Publish Date 15 Aug 2017 Bryce UrestiAntonio Alexander

Time Management can be very easy but also complicated based on schedules. But with [..]