For each StepResult, add StartTime with UNIX time offset

[Mr._Jim]

Looking at any step result, there's a TS.StartTime property, but it's referenced against the "the number of seconds since the application initialized the TestStand Engine"

What this means is that each step result is referenced against a somewhat arbitrary and changing epoch that isn't recognizable outside any one instance of the TestStand application, let alone by external applications.

I'd like to propose adding TS.StartTimeUnix, which contains the absolute time the step started.

I've added this in our model customization plugins, but to convert the epoch to UNIX I have to perform this calculation:

Seconds(False)-Seconds(True) + Parameters.Result->TS.StartTime

Why I'm asking for this:

In our step result database table, we've added a column for STEP_START_DATE_TIME which is absolute UTC time. To populate this I have to go through the gymnastics above. I revisited this code today and thought, "What silliness. This should be something natively supported." (Other than that I have no strong opinion on the matter)

[PhillipBrooks]

https://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Add-a-native-DateTime-data-type-to-the-TestStand...

[Mr._Jim]

Hey there Phillip, thanks for the empathy! I figured I'd just start with asking for an epoch that is darned near universally accepted and platform independent. At least then we have myriad options for calculations via external calls without jumping through too many hoops. baby steps.

For what it's worth, I use .NET DateTime and DateTimeOffset calculations all day long for this stuff using the .NET adapter. I guess I've long made my peace with the lack of native date and time calculations in TestStand. I added "utility" sequences that encapsulate these kinds of calculations so users including me don't have to think too hard about it, which sounds similar to what other people are doing using C# or LabVIEW.

TestStand team, kindly just give us the 1970 epoch at least, please? That's all I'm asking for for now.

(unless I'm missing something and making a fool of myself because I don't know it exists!)

[PhillipBrooks]

After accounting for timezones, epochs and daylight savings; a UTC timestamp would seem a natural addition.  I haven't done much with TestStand lately, but it looks like my idea will never rise to the level of being a feature. 

My use case was way back with TestStand 4 where I had to upload results into an Manufacturing Execution System. The MES test result table had a timestamp field, but no duration field defined.  Converting between various epochs, I wanted scream!  TestStand has added lots of reporting and process model features since then that can help with calculations, but timestamp is stil wanted.

Another case was running ESS testing where we wanted to run for N hours. Different test sequences can have different loop times, so we would calculate the average time while running and then before starting another loop check if there was time to complete another run. This way we could reliably schedule our chamber and production schedule.

[crossrulz]

I use the following to get the time of the module:

RunState.Engine.SecondsAtStartIn1970UniversalCoordinatedTime + Parameters.Result->TS.StartTime

[Mr._Jim]

@crossrulz, that's brilliant! How did I miss those properties, having been through the engine API so many times? Thank you! (Not a solution to what I'm asking for per this idea, but such a great tip!)

"Here, The Cheat, have a trophy!" (Inside dorky reference for the uninitiated)

[crossrulz]

Agree, it is not the idea.  I was the first to give this idea a kudos.  Unfortunately, I am not able to give it another one.