LabVIEW
Time Zone Conversion Issue
Hi JHess,
that's why I use 24h format:
In central Europe the DST already ended last week, so no problem here! 🙂
Btw. I always use ISO8601-compliant timestamps in my (text) files, so no problems with timezones/DST at all!
It works for me.... But we are currently in Standard Time
But try adding something like this to determine if your timezone is currently Daylight Savings Time or Standard Time, then make the correction if DST=1
Timestamps can be a surprisingly complicated thing to deal with. We don't usually think about it, maybe occasionally we miss an appointment when the daylight savings time gets active because we forgot to adjust our watch but with mobile phones being always connected and automatically adjusted and being our time keeper, this has gotten less frequent too.
For computers however is our handling of time and dates utter madness. 😁
That's why things like UTC have been invented. They allow to define a time that is independent of where and when the time measurement was made. Arithmetics on time should always be performed in UTC space, since it is a linear timescale without strange inconsistencies (well there is one small one actually and that is the leap seconds that get sometimes added because of the irregularity of the earths path around the sun, but that is for many measurements not relevant and can be ignored). There is also UT1 which is the astronomical time based on the exact position of earth on its path around the sun. This changes slightly but is generally always a tiny bit slower than UTC, so that occasionally (about once every 2 years on average but intervals have been as short as 1 year in the 1970ies when leap seconds were invented to about 3 years recently. Yes earth is slowing down but the differences observed in this leap second interval have other causes such as earthquakes, the movement of the earth mantel around the core changing earths inertia and even the glacial rebound has a measurable effect. The slowing down of earth in itself would only amount to about 2ms per century.
There is also TAI (International Atomic Time, the abbreviation looks backwards because it is in French) which was set in 1972 to be equal to UTC and has since been drifting away 27 seconds from UTC.
The practice of adding leap seconds to UTC is however planned to get abandoned until at latest 2035 because of the distortions they cause to time measurements with computers and connected services all around the world. One problem less to worry, when trying to do high-frequency trading with computers!
Basically you need to know what time-zone your textual timestamp is in, and apply that offset correctly when converting it to a numeric timestamp. LabVIEW timestamps are under the hood always in UTC, just as pretty much all computers treat timestamps internally. But since humans are not as good in observing offsets most often the timestamps are translated to local time when presented as text. LabVIEW by default does that too. But you can for instance let it format the timestamp in UTC by changing the format code for the indicator from "%<some time codes>T" to "%^<some time codes>T"
Properly converting a text timestamp to a numeric timestamp is a little tricky. But there have been many posts on these forums where various people have made a stab at this. Some are pretty good, but none can make it foolproof. There are always ways to mess up even if you think you fully conform to ISO 8601.
https://forums.ni.com/t5/LabVIEW/How-to-format-string-03-31-23-15-44-into-a-time-stamp/m-p/4309000
https://forums.ni.com/t5/LabVIEW/quot-Scan-From-String-quot-ignores-time-zone/m-p/4294791
https://forums.ni.com/t5/Example-Code/ISO-8601-compliant-date-time-string-in-LabVIEW/ta-p/3507833
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KqxSAE
