Writing LabVIEW timestamps to tdms

[jcopetre]

I'm unable to find information detailing how tdms timestamps work. I know that LabVIEW timestamps are all 128bit UTC times and that only their representations are subject to daylight savings time handling (i.e. using ^<>T vs <>T formatters in the LabVIEW indicators). I know that DIAdem does not use the 128 bit times. LabVIEW's TDMS Write.vi therefore must do some conversion when writing timestamp data to tdms. 

I am able to generate a vector of timestamps spanning 0200 2019-03-09 (a daylight savings time event in some locals) and I can write these to tdms. No matter how I generate these timestamps, whenever I view these timestamps in DIAdem, they will always reflect a +1 hr timeshift. This makes me think that DIAdem or the tdms specification is localizing the timestamps. If so, is there a way to disable this?

[NickelsAndDimes]

Hi jcopetre,

There are a few things I'd like to point out here:

1) The LabVIEW Timestamp datatype counts the seconds since New Year's Day 1904 (Gregorian Calendar, ignoring leap seconds), and the fractions of a second since that last second. (Sounds like you were already aware, but I wanted to link the documentation just in case)

2) Depending on how your data is acquired, you might not actually have a timestamp for every point, but rather a "t0" and "dt" value. t0 is the timestamp of your first data point, and dt is the time between each data point. From there, every other timestamp is calculated rather than being logged individually (If you're using a LabVIEW waveform, this is how timestamps are handled). '

Why are you looking to disable the way DIAdem handles daylight saving time? Is it preventing some functionality from working as expected?

[jcopetre]

In my case, I'm not writing waveform data but several groups of channels each with their own time vectors. To keep it simple, each group is defined by some DAQ task and each acquisition is given it's own LV timestamp. It appears that previous developers were unaware of how LabVIEW timestamps work as they implemented this exactly I suppose without bothering to read the very next comment in the thread. I suspect this implementation is at least part of the issue I'm having.

The issue specifically is that I was acquiring test data and this wonky implementation hit 0200 on 2019-03-10 which, for the local timezone, triggered a time change. This caused a discontinuity in the basis of my data. I'm trying to figure out how to undo this time jump without editing all of my data files--I'd prefer to just subtract the hour from the offending times. However, when I do this, DIAdem still appears to apply the time change yet I can view the data using both LabVIEW nptdms without witnessing discontinuities. 

[Brad_Turpin]

Hi jcopetre,

I fully expect that the time jump you're seeing in DIAdem is an artifact of the way DIAdem is loading the time information from the TDMS file.  I do NOT believe there is any time conversion happening when you are writing the time information from LabVIEW to the TDMS file, and your wraparound LV=>TDMS=>LV test results confirm this belief.

DIAdem has historically displayed loaded times in the local time zone of the DIAdem computer, and that includes the daylight saving time (summer time) jumps that occur twice per year at 2:00am in the US.  DIAdem has also historically loaded time values into a DBL channel, recording the number of elapsed fractional seconds since 0 AD, and since each DBL value has only 64 bits, the full 128 bit time resolution from the TDMS file can't be loaded.  DIAdem handles the display of the datetime strings dynamically, based on the DBL number that is stored in the "datetime" channel.  DIAdem 2018 actually has two modes for time channels, though, where this old DBL approach is the default mode for backwards compatibility.  If you enable the alternative mode,  you will be able to see vastly improved time resolution down to the nanosecond level or better, for DIAdem datetime channels.  It's possible that this alternative mode will help you with your current DIAdem struggle.

What DIAdem version are you using?

Could you post one of these TDMS files that loads different time values in LabVIEW vs. DIAdem?

Brad Turpin

DIAdem Product Support Engineer

National Instruments

[NickelsAndDimes]

Hi Brad,

Just to confirm, are we talking about the time channel settings in the "Display" window for the graphs (with options "Compatible", "Absolute", and "Relative")?

[NickelsAndDimes]

Or is this in the DIAdem settings, General Tab: "High Resolution for Absolute Time Values"?

[jcopetre]

Hi Brad--thanks for the detailed response here. I'm using DIAdem 2017 and LabVIEW 2016. Fix Times.zip attached is a sample that I've also submitted to NI Support--I think NicklesAndDimes may be one of the support reps I've been working with as well. Fix Times.vi has some OpenG requirements but simply adds an hour to the time vector found in source.tdms, saving the result to target.tdms. Preview.png is the result of a DIAdem append of both of these time vectors and illustrates apparent different behavior depending on where the DIAdem instance is localized (PDT and EDT demonstrated). The spike is from the original source data which is--I suspect--due to the spring forward event that would occur at 0200 on March 10; there are issues with this likely due to that my team isn't generating timestamps appropriately (we use this implementation for reasons unknown) but I suspect that the visualization issue is separate from the timestamp generation issue.

[Brad_Turpin]

Hi jcopetre,

I was referring to the DIAdem settings dialog, General Tab: "High Resolution for Absolute Time Values".  Those other display parameters are for the specific graph.  If you're seeing datetime values at all on your graph, you've got that set right.

Brad Turpin

DIAdem Product Support Engineer

National Instruments