I am trying to calculate a duration within an Automation, by reading two date and time stamps from a table, subtracting the end time from the start time and writing the result back into a Duration field in the same table. If I do this calculation within an App, it works fine, but if I try the same calculation within an Automation, the result seems to be multiplied by 60,000. Anyone know why this would be?
Hi Brian,
Welcome to Tulip Community 
and thanks for your question!
My first thought is something with the time conversion (for example, from ms to min is a conversion of 60,000). Are the two date stamps you are using the same units (ex. both in seconds) in app expression editor and automations expression editor? It may be helpful if you can share a screenshot of your expression as well so we can look at that in more detail.
Potentially this could be a bug, but want to confirm some of this information first before jumping to that conclusion!
Hi Beth, I have an Automation that monitors the change in a machine state, and records the start and end times of each uptime and downtime period in a table using the current date and time function within the Automation, so the date stamps are all sourced from the same place, so they should all be of the same format - screenshot attached of the table that gets populated. Whenever an end time is recorded, the Automation then tries to calculate the duration between the start and end times for that period. The table shows the result that a straight subtraction of the two time stamp within the Automation gives (Uptime Duration), and to get the answer to make sense, I have to divide that basic calculation by 60,000, as shown in my second screenshot, which i then write into the table in the Uptime Period (mins) column. Hope this makes sense.
Brian,
Thanks for the additional details here! I checked this with the Tulip product team, and this is indeed a bug. We have a ticket filed and are working on fix that will be in the next release (r278). Thank you for bringing your question and helping to point this out to us!
I will follow up here once r278 is released to confirm the fix.
This should now be resolved from Release 278 - April 2024! thanks for bringing it up @brian.petrie 