04-29-2010 02:23 PM
04-29-2010 03:38 PM
This is an easy explanation.
Excel stores daytime as a number. 1.000= midnight 1 jan 1900 and 2.000 = midnight 2 jan 1900 in the system time zone. So excel really has a different epoch (base time) depending on the system time zone. Someone way back when made this "foolish mistake" and we all live with it. To convert from TDMS timestamp to a local time in excel would require knowing where the workbook would be opened not where its written and everyone who opened the workbook could get a different time displayed because the machines may be in different timezones.
To avoid this the TDMS timestamp is converted to text before it is imported by excel and the time zone that makes the most sense UTC is used. Everyone can figure in UTC but only a few people in Kathmandu would be interested in UTC+5:45.
04-30-2010 07:28 AM
I don't think this is an Excel issue, but rather a TDMS issue - while LV keeps track of both UTC and the local offset, TDMS just stores the UTC information. I understand that you wouldn't want to figure the offset when you import the tdms file because the file write and file import don't necessarily happen in the same place.
So wouldn't it make sense to store the writing machine's local offset in the tdms file and calculate local time on import? Alternatively, give me the option of saving it with the offset built in.
I didn't like having to do this:
05-03-2010 03:49 PM
I'm not sure if you have an outstanding question still but as for your thought about the option to save the local time, you can always make a product suggestion or use the LabVIEW Idea Exchange (which it seems like you've used quite a bit).
If you did still have a question, let us know.
05-03-2010 04:32 PM
Just wanted to make sure I was right about the behavior and see if anyone had some input on their standard practice or a better workaround. Thanks for the link to the suggestion box, seems a bit of a niche idea for the Idea Exchange.