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]
pgpn3sPWvmStD.pgp
Description: PGP signature
