12-18-2015 01:12 AM
hi,
i have database table in UTC epoch field.i want to select and insert data from database table based on labview timestamp controll.
example:
table:
S:no U.name PWD Epoch(UTC 1970)
1 kumar 123 1450422341
2 sham 786 1450421623
the labview epoch is difference from UTC epoch. so ADD this second 2082844800 to labview epoch than it will work for selection quary but insert epoch is not work.
Solved! Go to Solution.
12-18-2015 03:16 AM
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.
12-18-2015 09:24 AM
Here is how I convert a LabVIEW time stamp to an Excel (OLE) timestamp.
Red the explainiation at the bottom and I am sure you can figure out how to change it to get use Epoch you need.
12-18-2015 10:11 AM - edited 12-18-2015 10:13 AM
An example of converting a LabVIEW timestamp to a *NIX # seconds since Jan 1,1970 can be found here (even with LV 8.2 download!)
https://decibel.ni.com/content/docs/DOC-3644
I would avoid using the kernel32.dll example and try creating the example I provided at the bottom. I used LabVIEW 2011 for the example, don't have 8.2 installed.
12-21-2015 05:09 PM
Well, Time 2 Excel rides again!
The Only problem with that vi.... DAMNED timestamp constants! Whitch is exactly what I feel you are hitting..... Timestamp constants do not travel well! they are tied to the system time settings. Don't get me wrong! that little vi has over a dozen solved threads on these forums! Its just that you need to pick a timezone for all of the target machines. Set them ALL up for UTC! Then, everybody plays along nice.
12-21-2015 05:17 PM
@JÞB wrote:
Well, Time 2 Excel rides again
The Only problem with that vi.... DAMNED timestamp constants! Whitch is exactly what I feel you are hitting..... Timestamp constants do not travel well! they are tied to the system time settings. Don't get me wrong! that little vi has over a dozen solved threads on these forums! Its just that you need to pick a timezone for all of the target machines. Set them ALL up for UTC! Then, everybody plays along nice.
While you make some valid points, try explaining to my manager why the timestamps are all eight or nine hours off.
12-21-2015 06:13 PM
@RTSLVU wrote:
@JÞB wrote:
Well, Time 2 Excel rides again
The Only problem with that vi.... DAMNED timestamp constants! Whitch is exactly what I feel you are hitting..... Timestamp constants do not travel well! they are tied to the system time settings. Don't get me wrong! that little vi has over a dozen solved threads on these forums! Its just that you need to pick a timezone for all of the target machines. Set them ALL up for UTC! Then, everybody plays along nice.
While you make some valid points, try explaining to my manager why the timestamps are all eight or nine hours off.
Windows
12-07-2016 08:23 AM
thank you
12-07-2016 12:54 PM
Paul Cardinale posted this nifty tidbit that calculates UTC offset a while back.
10-01-2024 12:33 PM
For Python users, the DST needs to be set to (0) Standard to convert LabVIEW's local time zone to Python's local time zone using:
from datetime import datetime
datetime.fromtimestamp(unix_utc_seconds)
This way the default settings in Python's datetime will resolve to the local time zone successfully.