10-10-2019 02:43 PM - edited 10-10-2019 02:44 PM
@Mancho00 wrote:
I love crossrulz's solution, but have to adjust for current timezone. Or just do this.
I think my solution is cleaner if you would rather calculate it and not worry abut time zones
10-10-2019 02:45 PM - edited 10-10-2019 02:47 PM
@RTSLVU wrote:My solution is cleaner if you would rather calculate it and not worry abut time zones
You forgot the Fractional Seconds. Also, this is where the Compound Arithmetic node can help (expand to 4 inputs in the Add mode).
EDIT: Oh, and this will probably still break on the days DST is started and ended. I would have to figure out what day that is in order to give it a try...But I am past time to go home.
10-10-2019 02:52 PM
I learned a lot. Had not used LabVIEW's timestamp very much in the past.
Thanks again.
10-10-2019 02:55 PM - edited 10-10-2019 02:57 PM
@crossrulz wrote:
@RTSLVU wrote:My solution is cleaner if you would rather calculate it and not worry abut time zones
You forgot the Fractional Seconds. Also, this is where the Compound Arithmetic node can help (expand to 4 inputs in the Add mode).
EDIT: Oh, and this will probably still break on the days DST is started and ended. I would have to figure out what day that is in order to give it a try...But I am past time to go home.
Actually I had the fractional seconds in there to begin with but took it out as I don't think the VB function the OP was trying to duplicate returns fractional seconds.
Interesting thought about DST start and end days...
But that is what UTC is for after all 😛
10-10-2019 03:04 PM
Also I am going to toss this out there just in case you notice there is a difference between LabVIEW and VB.NET raw timestamps...
The OLE (Windows, Excel, etc) date format is a double-precision floating point number that counts the time from 30 December 1899 00:00:00.
(Epoch 0 December 1899 00:00:00)
The UTC date that is returned from the LabVIEW functions is the number of seconds elapsed since 12:00 a.m., Friday, January 1, 1904.
(Epoch 12:00 a.m., Friday, January 1, 1904)
10-11-2019 05:40 AM
@RTSLVU wrote:Interesting thought about DST start and end days...
But that is what UTC is for after all 😛
Indeed. And one of the reasons I use UTC as the time zone on all of my test systems.
"Sea" story:
I inherited a system that was doing thermal cycles and it used the system time for calculating the soak times. DST kicked in during said soak time. Confusion insued when the thermal charts showed an extra hour of soaking. It took them several days before realizing DST was the cause. Their fix was to not test on the weekends DST transitioned.
10-11-2019 08:02 AM
For the purpose of number of seconds since midnight I do not think there will be issues an the LV logic will handle that without an issues.
The complication with DST is when we try to turn the seconds since 1904 into a time like 2:00 AM.
Ben
10-11-2019 09:17 AM
@crossrulz wrote:
"Sea" story:
I inherited a system that was doing thermal cycles and it used the system time for calculating the soak times. DST kicked in during said soak time. Confusion insued when the thermal charts showed an extra hour of soaking. It took them several days before realizing DST was the cause. Their fix was to not test on the weekends DST transitioned.
OMG! That's funny...
Patient: Doctor, it hurts when I do this.
Doctor: Then don't do that.