From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Date/Time To Seconds bug only on march

The screen shot is self explanatory

 

Only on a specific  date and time (on March) timestamps is shifted in 1 hour. it doesn't happen a day before nor day after. so it can NOT be related to day light saving configuration. I have a good feeling this is a genuine bug...

I have seen this problem with other dates in other years. all of them are at march and a times after midnight.

 

VI is labview 2015.

 

Time to sec bug.JPG

0 Kudos
Message 1 of 4
(2,723 Views)

But it is probably related to DST!

 

Although I wonder which region you are in here. March 27 should be a Friday and normally DST changes on a Sunday

 

If I change your VI to a date of March 29, 2020 I see exactly the same behaviour.

 

March 29, 2020 happens to be the last Sunday in March, which is at least at the moment the expected time when DST will start in many European regions. And then the time jumps from 2:00 AM to 3:00 AM in one second and all the times in between are technically invalid. So is it a bug if you tell LabVIEW to convert a non existing time? 

 

What should happen in this case? Should LabVIEW tell you that it is 3:00 instead? Sounds even worse than what it does now.

 

If you want to avoid such issues with discontinuities in your absolute timescale you do have to work entirely in UTC. Otherwise you have to accept that there will be such nasty things, as there is no technical satisfying solution to conversion of non existing times.

 

With DST set to -1 you tell LabVIEW to determine itself if the timestamp is DST or not. If you set it to 0 it will convert the time to 3:40, since 2:40 in non DST is really 3:40 in DST and if you set DST to 1 it will convert it to 1:40 since 2:40 in DST COULD be considered 1:40 in non DST, which is also the default LabVIEW uses for such an ambigous input.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 4
(2,719 Views)

Thanks.

What I dont understand (it is expres in my screenshot):

 

March 26 - No DST (time is 02:40

March 27 - Has DST (time is 01:40)

March 28 - No DST (time is 01:40):smileysurprised:

 

 

 

0 Kudos
Message 3 of 4
(2,712 Views)

Now i even more puzzled:

 

I have changed "Date/time to seconds"  Is UTC?  to true.

Regardless to DST value in date and time rec cluster I expected to get the same value for all dates - but not..

Now i have tested march 24,25,26. I see references...

 

I am in GMT+2

 

Time to sec bug1.JPG

0 Kudos
Message 4 of 4
(2,706 Views)