<br clear="all">Kenn,<br> 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.<br>
<br><div> 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.<br></div><div><br></div><div>Wayne Thursby</div><div>System Administrator</div>
<div>Healthcare Management Enterprises, Inc.</div><div><br></div><div>(p.s. sorry for off-list reply)<br></div>
<br><br><div class="gmail_quote">On Tue, May 17, 2011 at 7:19 PM, Kenneth Crocker <span dir="ltr"><<a href="mailto:kfcrocker@lbl.gov">kfcrocker@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Kevin,<br><br>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.<br>;-).<br><br>Kenn<br>LBNL<div><div class="h5"><br><br><div class="gmail_quote">On Tue, May 17, 2011 at 2:34 PM, Kevin Falcone <span dir="ltr"><<a href="mailto:falcone@bestpractical.com" target="_blank">falcone@bestpractical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, May 17, 2011 at 02:02:58PM -0700, Kenneth Crocker wrote:<br>
> That's odd. I use Emmanuel Lacour's code for 3.8 and I don't have this problem. My users can<br>
<br>
</div>Kenn, the 3.8 date custom field patch and the 4.0 datetime custom<br>
field types have very little in common.<br>
<br>
In fact, there really isn't an upgrade path between the two due to the<br>
various bugs in the patch and general improvements in Custom Fields in<br>
4.0<br>
<br>
-kevin<br>
<div><br>
> enter "2011/11/25" or "20/22/2011" or pick a date from the Calendar pop-up and it is always<br>
> interpreted correctly into our preferenced format of yyyy-mm-dd. DId you set a default date<br>
> format preference in your configurations? Ours drops the time element (since we really don't<br>
> care what time something was done).<br>
><br>
> Kenn<br>
> LBNL<br>
><br>
</div><div>> On Tue, May 17, 2011 at 1:42 PM, Wayne Thursby <[1]<a href="mailto:wayne.thursby@hcmeinc.com" target="_blank">wayne.thursby@hcmeinc.com</a>> wrote:<br>
><br>
> The date custom field is a welcomed addition, and opens up a lot of possibilities.<br>
> Everything works great, but I've noticed one assumption it makes that is, at least in my<br>
> case, an incorrect one.<br>
><br>
> Instead of selecting dates from calendars, my users type in dates manually. I am in America,<br>
> so this follows the (admittedly silly) format of "MM/DD/YY"<br>
><br>
> If the users manually type in a date such as the 25th of August, 2010 as "8/25/10", the date<br>
> is correctly interpreted by the custom field.<br>
><br>
> However, when a more ambiguous date is entered, such as the 9th of August, 2010, the date is<br>
> incorrectly parsed as being in the international (and more rational) format of "DD/MM/YY".<br>
> This turns the user's intended input, "8/9/10" into meaning the 8th of September, 2010.<br>
><br>
> Computers are typically easier to configure than users. Is the default format for date<br>
> CustomFields configurable? If not, should I file a feature request?<br>
> Wayne Thursby<br>
> System Administrator<br>
> Healthcare Management Enterprises, Inc.<br>
><br>
</div>> References<br>
><br>
> Visible links<br>
> 1. mailto:<a href="mailto:wayne.thursby@hcmeinc.com" target="_blank">wayne.thursby@hcmeinc.com</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>