Kenn, I'm not sure how the 3.8 custom patch stores its information, but all RT 4 requires is a string in the "Content" field of ObjectCustomFieldValues of the form "YYYY-MM-DD". I wrote a quick script to convert our user input of "MM/DD/YY" to the other format, and simply changed the custom field type to Date, and everything worked as expected.
As long as the custom patch used a consistent format and stored its values the same way as other custom fields, conversion should be straightforward. Wayne Thursby System Administrator Healthcare Management Enterprises, Inc. (p.s. sorry for off-list reply) On Tue, May 17, 2011 at 7:19 PM, Kenneth Crocker <[email protected]> wrote: > Kevin, > > Well, I guess that means I'll have a lot of DB work to do to preserve the > CF Dates when we upgrade to 4.0. > ;-). > > Kenn > LBNL > > > On Tue, May 17, 2011 at 2:34 PM, Kevin Falcone > <[email protected]>wrote: > >> On Tue, May 17, 2011 at 02:02:58PM -0700, Kenneth Crocker wrote: >> > That's odd. I use Emmanuel Lacour's code for 3.8 and I don't have >> this problem. My users can >> >> Kenn, the 3.8 date custom field patch and the 4.0 datetime custom >> field types have very little in common. >> >> In fact, there really isn't an upgrade path between the two due to the >> various bugs in the patch and general improvements in Custom Fields in >> 4.0 >> >> -kevin >> >> > enter "2011/11/25" or "20/22/2011" or pick a date from the Calendar >> pop-up and it is always >> > interpreted correctly into our preferenced format of yyyy-mm-dd. DId >> you set a default date >> > format preference in your configurations? Ours drops the time element >> (since we really don't >> > care what time something was done). >> > >> > Kenn >> > LBNL >> > >> > On Tue, May 17, 2011 at 1:42 PM, Wayne Thursby <[1] >> [email protected]> wrote: >> > >> > The date custom field is a welcomed addition, and opens up a lot of >> possibilities. >> > Everything works great, but I've noticed one assumption it makes >> that is, at least in my >> > case, an incorrect one. >> > >> > Instead of selecting dates from calendars, my users type in dates >> manually. I am in America, >> > so this follows the (admittedly silly) format of "MM/DD/YY" >> > >> > If the users manually type in a date such as the 25th of August, >> 2010 as "8/25/10", the date >> > is correctly interpreted by the custom field. >> > >> > However, when a more ambiguous date is entered, such as the 9th of >> August, 2010, the date is >> > incorrectly parsed as being in the international (and more >> rational) format of "DD/MM/YY". >> > This turns the user's intended input, "8/9/10" into meaning the 8th >> of September, 2010. >> > >> > Computers are typically easier to configure than users. Is the >> default format for date >> > CustomFields configurable? If not, should I file a feature request? >> > Wayne Thursby >> > System Administrator >> > Healthcare Management Enterprises, Inc. >> > >> > References >> > >> > Visible links >> > 1. mailto:[email protected] >> > >
