Jump to content

Converting Windows Time From Labview Time


Recommended Posts

The LabVIEW timestamp is different from 'C' timestamp. The origin dates are different. LabVIEW is Jan 1, 1904. 'C' time is Jan 1,1970.

If your passing timestamped data between LabVIEW and C you will need to adjust the LabVIEW timestamp by 66 years in seconds.

However, different values for the offset have been suggested. The correct offset in seconds is: 208138000 - this is simply 31536000 (a years worth of seconds) x 66(years)=2081380000.

To check, if you recovert the seconds back into LabVIEW time the clock should be off by 66 years but the hours and time of day should be the same. Some constants proposed have a 1 hour offset. (Although I am scratching my head about leap years which logically should subract a day for every 4 years. (16.5 days for 66 years) but the simple calculated offset is still correct)

Regards

Jack Hamilton

Link to comment
To check, if you recovert the seconds back into LabVIEW time the clock should be off by 66 years but the hours and time of day should be the same. Some constants proposed have a 1 hour offset. (Although I am scratching my head about leap years which logically should subract a day for every 4 years. (16.5 days for 66 years) but the simple calculated offset is still correct)

Actually, Jack you are right, there is a leap year issue. I'm not sure why it is working for you because it is NOT working for me. I think you should NOT just subtract the 66 years in seconds. You should be subtracting the number of seconds until jan 1 1970 from 1904.

post-10-1073411118.gif?width=400

Link to comment

:clock:

Here is a VI that outputs all three time references Jan 1, 1904, 1970 & 1980. Keep in mind that the LabVIEW "Seconds to Date & Time" will not resolve the date correctly for the 1970 and 1980 reference.

This VI does not simply subtract 66 years, but calls the time convert function in LabVIEW which (*should*) perform all the proper timezone and leap year adjustments.

You should see the today's date in the 1904 reference, the same time but 1970 in the 1970 box and etc for the 1980 box.

Good Luck.

Download File:post-10-1073579950.vi

Link to comment
  • 1 year later...

Sorry but your VI outputs the wrong times. You really need to calculate the number of seconds elapsed between the 1904 date and 1970 date. Simply subtracting the year doesn't solve the problem.

Anyway, in my case I needed that number of seconds to subtract to adjust the 1904-based mac date to 1970-based unix date. The value above in the first message of the thread gave me a 16-day offsetted date. So I calculated my own number: 2082816000. This is the number of seconds elapsed between 1/1/1904 and 12pm 12/31/1969. I used the attached VI Download File:post-2734-1123703905.vi to ask LabVIEW this number and write the timestamp into a file. Unfortunately, I couldn't find an easier way to get this number, since there are no 64-bit integer data types in LabVIEW.

You can run the vi, it will ask for a file name. Looking in the newly created file you will get the above number in HEX and in big-endian format.

It's curious google doesn't give this number.

I hope this time it's right.

-Cengiz

:clock:

Here is a VI that outputs all three time references Jan 1, 1904, 1970 & 1980. Keep in mind that the LabVIEW "Seconds to Date & Time" will not resolve the date correctly for the 1970 and 1980 reference.

This VI does not simply subtract 66 years, but calls the time convert function in LabVIEW which (*should*) perform all the proper timezone and leap year adjustments.

You should see the today's date in the 1904 reference, the same time but 1970 in the 1970 box and etc for the 1980 box.

Good Luck.

280[/snapback]

Link to comment
Sorry but your VI outputs the wrong times. You really need to calculate the number of seconds elapsed between the 1904 date and 1970 date. Simply subtracting the year doesn't solve the problem.

Anyway, in my case I needed that number of seconds to subtract to adjust the 1904-based mac date to 1970-based unix date. The value above in the first message of the thread gave me a 16-day offsetted date. So I calculated my own number: 2082816000. This is the number of seconds elapsed between 1/1/1904 and 12pm 12/31/1969. I used the attached VI Download File:post-2734-1123703905.vi to ask LabVIEW this number and write the timestamp into a file. Unfortunately, I couldn't find an easier way to get this number, since there are no 64-bit integer data types in LabVIEW. 

You can run the vi, it will ask for a file name. Looking in the newly created file you will get the above number in HEX and in big-endian format.

It's curious google doesn't give this number.

I hope this time it's right.

-Cengiz

5613[/snapback]

I think you made a significant mistake in the calculation as you did not take into account your current time zone offset. I am not entirely sure this calculation holds true either but the result of 2082840000 would be more appropriate assuming both reference dates are supposed to be GMT which in general is the right thing. If you calculate the the quotient and remainder from this number with 86400 you get a quotient of 24107 and a remainder of 0, indicating that there are indeed exactly a full number of days in between.

Attached is the diagram of the VI I used to calculate that offset. This should be independent of the time zone you are in.

post-349-1123831921.jpg?width=400

Link to comment
  • 3 years later...

I know this is an old thread, But I am amazed at all the numbers thrown around in this posting that are incorrect.

Just in case you need to know, and don't want to work it out for yourself, the number of seconds elapsed between the first days of 1904 and 1970 is 2082844800.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.