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.
Example:
- Drag and drop VI snippet above into an empty VI
- Run the VI to print the current time
- Change the time zone
- Restart labVIEW
- Run example again
- 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.
