Update 15/02/08 - Partial solution provided by Microsoft Support. As this is not exactly a supported fix, please contact me privately for details or leave a comment and I'll contact you.
CRM 4.0 coming out just at the turn of a year and customers going from 2007 to 2008 in various date fields raised an interesting bug.
The problem is with saving forms where I try to enter a date at the beginning of any year like 01/01/2008 I get the following error:
This error basically states "Invalid Argument" for the newly entered date value. Which is odd, as this is a real date.
Turning on the DevError flag produces the following output when I attempted to open anything saved with a "bad" datetime value. This was followed by a long stack trace.
System.ArgumentOutOfRangeException: Specified argument was out of the range ofAfter studying this problem further, I came across an interesting behavior. I changed the datetime field so it would not just show the date but also the time values. I then started playing with the time values and attempting to save each time. This problem only arrose between 12:00am and 02:00am (02:00am was the first time value that allowed me to save). This seemed odd but then I remembered my user was configured to work in the GMT+2 time zone. I Then attempted this with the GMT+5 time zone and it behaved in the exact same way apart for it starting to work properly at 05:00am.
valid values.Parameter name: GetDaylightChanges actual year: 2007,
MinValue.Year: 2008, MaxValue.Year: 9999
This all struck me as being very odd. To try and narrow down the issue, I wanted to see if this only happens when moving between years or if it also arrises on the first day of any given month. I quickly attempted to enter a new date as the 01/02/2008 (first of feb) with different time values but they all worked. It appears the problems only happen when moving between years.
I'd just like to add that this happens with all date fields in the system. Default and custom entities with default or custom datetime fields. Any mix will do, all you need is a datetime field.
To sum up the results from my various checks, this problem only seems to happen when the value entered in any datetime field changes year values (ex. 2007 and 2008) when comparing the local time zone and the GMT time zone datetime values. This can be reproduced by entering a value on 01/01 of any year with a time value which is lower than your local GMT offset (ex. 01:30am for GMT+2 or 04:30am for GMT+5).
In addition, I have also performed the exact same tests on 3 different CRM 4.0 deployments in both clean installation and upgraded (from CRM 3.0) environments. They all performed in the exact same way.
Microsoft have provided me with an unsupported SQL script which temporarily fixes the issues described in this post. However, I would rather not make this fix publically available as it does involve directly editing the CRM databases.
A permenant hotfix will be made available for this matter shortly (I hope). I will post an update once this happens.