Monday, September 24, 2012 5:54 PM
We discovered some odd behavior with what timestamp is recorded for date fields in our WIT. (We're using TFS 2010 on Win 7).
The WIT is set up to just show the date, but when you save the record, the field records both a date and a timestamp in the DB. The timestamp is the point in time when the date field was activated (check box is checked).
If you change the date later, the timestamp does not update. I expected this as that field doesn't show the timestamp to edit, so the DB is holding on the original value. What is weird is when you clear the date field (check box is unchecked), save the record, and then reactivate the field with a new date, the timestamp doesn't reset! Even though the field was NULL after I cleared the box and saved, it still seems to remember the old timestamp and will reuse it when I reactivate the date field.
I found that if I go through a sequence of steps, it sometimes resets the time (Clear date field, save, close record, open record, reactivate field, save record), but not always. Sometimes I have to refresh the whole project and then go through the sequence to get the time to reset.
Obviously the workaround is to just change the control to show the timestamp, but I'm wondering if this has been seen before, is a known bug? Is there a way to get the timestamp to update when you just add the date without changing the control?
Thanks for any help/information provided on this.
Monday, September 24, 2012 6:21 PM
Ooh - I think I found why its acting weird. I opened the WIT in an XML editor and found this:
<Control FieldName="Myfield.InitialAck" Type="DateTimeControl" Label="Initial Acknowledgement:" LabelPosition="Left" Format="Custom" CustomFormat="MM/dd/yyyy" />
<Control FieldName="Myfield.ResolutionNote" Type="DateTimeControl" Label="Root Cause Notification:" LabelPosition="Left" Format="Custom" CustomFormat="MM/dd/yyyy" />
When I removed the custom format and leave it as the default format for that control, it would correctly update the time stamp.
I think given that the timestamp needs to be accurate for those fields, its probably still best policy to have the timestamp exposed as an editable part of the field.
I did see that the odd behavior noted above happens with any custom formatted date field, so even if I expose the timestamp, it still may keep the old value even though the field is NULL in the DB.
Monday, October 01, 2012 9:16 AMModerator
Thanks for your post!
The Format attribute is valid only when it is used with DateTimeControl. Specifies the format for the date-time field corresponding to one of the values of the DateTimePickerFormat enum. The DateTimePicker control displays the date/time value in a custom format. For more information, see CustomFormat.
Based on your description, the date fomat seems not set correctly. The format strings can be combined to format the date and time. For example, to display the date and time as 06/15/2001 12:00 PM, this property should be set to "MM'/'dd'/'yyyy hh':'mm tt". For more information, see Custom Date and Time Format Strings.
Hope it helps!
Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
Tuesday, October 02, 2012 10:37 PMThanks Cathy. I'll poke more into it to see if I messed the formating string up. It looks correct and saves correctly in the DB, so its just the TFS template behavior that is acting up when I use a custom setting.