LabVIEW
how to change labview timestamp epoch to UTC epoch
Solved!
@Sam_Sharp wrote:
UTC is essentially just a timezone - it doesn't have an 'epoch' (well... year 0 in gregorian calendar). Unless you mean the Unix epoch?
The LabVIEW timestamp starts at 01/01/1904 00:00:00.00 UTC
The unix epoch is 01/01/1970 00:00:00.00 UTC
(Note how both times are expressed in UTC!)
If you use the 'timestamp to number' VI, it will convert the LabVIEW timestamp into the number of seconds since the LabVIEW start time. You can then add the 66 years worth of seconds to it to convert it to the Unix epoch.
This is basically the principle of calculating the difference. Because the epochs for both systems is defined relative to UTC (technically UTC didn't exist in 1904 so it is GMT for the LabVIEW timestamp, but with exception of potential leap seconds they can be considered the same).
Basically if you take the value of a LabVIEW timestamp, configured to display in UTC and enter January 1, 1970, 00:00 in it and then convert that to a double precision value you have the constant offset between the two epochs (2082844800). Subtract this value from the LabVIEW timestamp to get the Unix timestamp and vice versa. Since the offset is really constant and there is no timezone offset involved (both time epochs are defined in terms of UTC/GMT) that always works.
Note: This will create a timestamp that is "universally" correct. That means if the event happened in India at 17:30 and you correct with above offset to a Unix timestamp you will get a value of 12:00 if formatted into UTC through datatime.fromtimestamp() and 7:00 if your computer is in New York. And while this may seem weird to some people and they would rather see the local time of where the event happened, you are then getting into the realms of timezone differences and correction and that is a nasty thing to tackle properly since timezones are not only location specific but also time specific. DST correction change times are happening at different moments on different locations and there are other timezone changes over the course of the years in quite a few locations on earth.
Scientifically it is definitely more useful to know the universal time of an event but many people feel more comfortable to see the local time of the event even if it happened at a very different location and in universal terms at a different time than what they are in themselves.
The code in the last post gets to a different offset since it makes a bad assumption. The timestamp entered in the constant is in local time but the "Timestamp to DateTime" function is told to convert the DataRec into UTC. Then it manipulates the DST flag to tell that the DateRec is not in DST,, which it should be anyhow already since it is not local time and then converts it back into a timestamp telling the function that the DateRec is in local time. Bamm, you magically added the timezone offset to the resulting timestamp. But the numeric value in a LabVIEW timestamp is ALWAYS considered to be in UTC. Since it isn't anymore you need to add a different offset to get back into a correct Unix timestamp value. The offset used contains the local timezone offset in this case (4 * 3600 seconds).
If the VI in the previous post is used in a different timezone/DST situation, it will get a wrong result. The real solution is as simple as this and will work in all timezones:
