LabVIEW
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.
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.
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
