Hilarious and sad all at once...I reviewed this post 11 years after I originally wrote it and lo and behold, the use case scenarios are still applicable but little has changed in the platform. Read onwards and replace the year 1900 now with 1753. You can also replace Scribe with TIBCO and now might even consider a Power Automate Flow or even a Canvas App to better accommodate these older dates....
-------------------ORIGINAL POST----------------------------
It's a not-so-well known issue that all major releases of CRM to date have not supported any dates earlier than 1/1/1900. So, the question persists..."Can a date/time field in CRM 2011 select/store a value older than 1/1/1900?". The answer is NO.
In most cases, this won't be an issue so it would seem the point is moot. However, there are definite use case scenarios I've encountered where we've had to use work-arounds to facilitate selection and storage of dates older than 1/1/1900. One example was with an collectible brokerage/auction house that needed to store the date of origin for each product they catalogued.
We had to dis-assemble the date into five separate fields: YYYY, MM, DD, OriginDateTimeString, and OriginDateTime. Then, we used client side code to piece together the user entered valued to build a properly formatted string value that we could use for SQL date aggregation. That's where the tricky part came in.... Having the date value in string format - even if it carries the proper format - doesn't allow for native SQL aggregation unless the attribute type is of datetime. That's why we have the last field that is of true DateTime format. Using a middleware tool like Scribe, it is easy to translate the formulated string date into a true DateTime value and update the true DateTime field. An alternate method would be to create a custom CRM workflow plugin to allow conversion of a string into a date field based on a couple/few pre-determined string formats (e.g., UTC, etc.). We were fortunate enough to have Scribe, so we ripped it out in a few minutes....
Other good examples of where this limitation might come into play would be a company that manages family trees and ancestries. How about a classic/antique car dealership? Even possibly a historic event tracking organization (like NEHRP - the National Earthquake Hazards Reduction Program) that may need to track and store distant histories to calculate future events.... The list goes on and on, so if you find yourself in a situation where you need to store dates older than 1/1/1900, just try breaking it apart a bit. Don't forget to deprecate any redundant system fields though (like Contact..birthdate), otherwise users could get confused pretty quickly!
Who knows, maybe we'll see an Update Rollup for 2011 that will finally give us this functionality OOB...! Cheers!
*This post is locked for comments