10-03-2009 01:34 PM
Maybe it's just me, but I can't seem to get any time stamp controls to accept 7PM as an entry.
....this is kind of a problem for the data entry I'm supposed to be doing this weekend.
Any workaround?
10-03-2009 04:02 PM
Hi Patrick.
I do not have any problems in setting "your" TimeStamp control to 7PM. I downloaded your snippet and set the default value to 7PM in my time zone, which is GMT + 1.
I do not have an idea what might go wrong on your computer.
Guenter
10-03-2009 04:37 PM - edited 10-03-2009 04:44 PM
Thanks for the reply Guenter.
It's very strange. Even after shutting down LabVIEW and starting with an entirely new VI, the time stamp control always displays 00:00:00 when I try to enter 7PM.
I've tried changing the defaults to just about everything. But it's always the same behavior.
For my work around I decided to just use Excel for all my raw data entry. I'll write program to stuff it all in the database later.
*edit*
I just downloaded the attachment on your reply.....and it worked just fine.
I'm uploading the entire .vi now. This is bizare.
10-03-2009 05:03 PM
This is curious, Patrick. I set the default value of your "Doesn't work" TimeStamp to 7PM, saved the VI, exited LabVIEW. When opening the VI, it correctly opens with a default value of 7PM.
Good luck, Guenter
10-03-2009 07:51 PM
Are you in the Eastern Time zone? I am in the Eastern Time Zone and I do see that behavior. If I set the control to 7:00:01 PM, it will take it. Then edit it to 7:00:00 PM and then it will stick. Anyone in other time zones should try entering a time for them equivalent to midnight GMT on January 1st, 1904.
One of the reasons why I think it sticks is that it interprets 7:00:01pm when the control is set for a two digit year to 7:00:01pm Dec 31, 2003 Then setting it for 7:00:00 pm leaves it at 7pm Dec 31, 2003 I didn't discover that it was set for 2003 until I did a To DBL conversion to a regular numeric indicator and saw it was at 3 billion seconds.
Overall, this is related to LabVIEW time being based on Midnight Jan 1, 1904 GMT. That is 0 seconds.
I'm not sure if this a just a quirk of LabVIEW's timestamp, or an actual bug. I remember participating in a recent thread about the timestamp control and I believe the increment/decrement control of it that had hints of this issue. But I just can't seem to find it.
10-04-2009 12:16 AM
Ravens Fan wrote:Are you in the Eastern Time zone?
Yes. I am in the Eastern Time Zone as well.
I recently ran into some weirdness with the increment/decrement controls as well. This project started in LV 8.5, and that was where ran into the problem. To correct it, I created a Time Stamp control on another computer that had LV 8.6 and then saved for previous version 8.5 The new control worked fine in 8.5 application.
Now the whole thing has migrated to 2009.
10-04-2009 10:30 AM
Thanks,
Knowing that you might have been in that same thread gave me the ability to search for it and find it. (It didn't jump out at me when I searched based on my name.)
For others, here is the link to that other thread describing the issues with the control. http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=424883#M424883
I'm wondering if this thread and/or the other thread ought to be considered bugs.
10-05-2009 03:42 AM
It is probably a data entry validation bug when entering a time that results into corresponding exactly to the 0 seconds since January 1. 1904 GMT.
However why would you want to do that?
Presumably when you really want to enter relative time without date and that is exactly what the timestamp control is not meant to be. Timestamp is absolute time and a normal numeric is relative time.
So the best fix for this is to use really a double precision numeric (or an unsigned int32 if you only need full seconds) and set its formating to relative timestamp.
Rolf Kalbermatter