We use WebDateTimeEdit for users to enter dates in dd/MM/yyyy format (we're in the UK). We also set the MinimumNumberOfValidFields property to 2 as the majority of dates entered are for the current year. This works as expected in the majority of cases and the users like the fact that they only have to enter 30/6, for example, to input a date of 30/06/2010.
There is a problem however when this is used for entering the last day of the month for months that have 31 days. For example, if they enter 31/8, it gets changed to 01/08/2010 when they leave the field. Returning to the field and entering 31/8 again produces the correct result when they leave the field. The problem does not occur if the year is entered (e.g. 31/8/10)
Any suggestions on how to correct this without having to force the year to be entered? We're currently on Infragistics version 8.3.20083.2039 for this application.
I have some fresh information on this.
The problem occurs depending on how many days there are in the current month (as specified by the system clock) when the control is used. So now that we've moved into October where the month has 31 days, the problem does not occur at all. However, if I change my clock to any month with 30 days, I see the problem when I enter 31st of any month but not 30th / 29th / 28th. Similarly, when I set the system clock to February, the problem occurs with both 30 (for 30 day months) and 31 (for 31 day months).
Can you clarify your comment that the control is expected to enter the full date in the format dd/mm/yyyy? Isn't the purpose of the MinimumNumberOfValidFields="2" to allow this behaviour as witnessed by the fact that it does work as expected in most circumstances?
ThanksIan
Hello Walker,
It looks that the WebDateTimeEdit control wasn't designed to enter only partial of the date format specified. In other words the control is expected to enter the full date in the format of dd/MM/yyyy.
Does it happen only when you enter 31st of any month? How about 30th or 29th?
Can you verify again that the expected result is still occurring?
Let me know if you have any questions with this matter.
Sincerely,Duane HoytDeveloper Support Engineer, MCTSInfragisticshttp://es.infragistics.com/support
Thanks for the sample which also displays the problem in our environment. The key point is that the problem only occurs when 31/8 is the first date entered into the field. Once any date has been entered and the user moves focus from the field, then it behaves correctly with 31/8. If the page is refreshed, the problem will then recur when 31/8 is the first date entered.
I've now tried this using 10.2 as well as IE7, 8 and 9, Chrome and Firefox on a number of different machines running a variety of OS and and the problem is always there.
Hello Walker, I created a simple WebDateTimeEdit sample with Culture UK using 8.3.20083.2039 but, was unable to replicate the issue as mentioned. On entering 31/8, it results with 31/08/2010 which is right. I have attached the sample for your convenience. Please update the sample to match your application or share a sample of your own in order for us to reproduce the issue from our end.
I look forward to hearing from you.
Thank you,
Swetha