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.
Wayne,
That’s odd. I use Emmanuel Lacour’s code for 3.8 and I don’t have this
problem. My users can enter “2011/11/25” or “20/22/2011” or pick a date from
the Calendar pop-up and it is always interpreted correctly into
ourpreferenced 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
LBNLOn Tue, May 17, 2011 at 1:42 PM, Wayne Thursby wayne.thursby@hcmeinc.comwrote:
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.
Hello Wayne,
Check DateDayBeforeMonth config option in the config. If it doesn’t
help then file a bug report.On Wed, May 18, 2011 at 12:42 AM, Wayne Thursby wayne.thursby@hcmeinc.com 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.
Best regards, Ruslan.
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
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
LBNLOn Tue, May 17, 2011 at 2:34 PM, Kevin Falcone falcone@bestpractical.comwrote:
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] wayne.thursby@hcmeinc.com> 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
- mailto:wayne.thursby@hcmeinc.com
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 kfcrocker@lbl.gov 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 falcone@bestpractical.comwrote:
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] wayne.thursby@hcmeinc.com> 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
- mailto:wayne.thursby@hcmeinc.com
Thanks for the quick reply Ruslan.
That was exactly what I was looking for. When looking through RT_Config.pm I
read the Date configuration part as only dealing with display, but now I see
the note “Used only for parsing, not for displaying dates.”
So, the correct setting for the usual American date format is:
Set($DateDayBeforeMonth, 0);
This has the desired effect of interpreting “8/9/10” as August 9th.
Wayne Thursby
System Administrator
Healthcare Management Enterprises, Inc.
(p.s. sorry for off-list reply)On Tue, May 17, 2011 at 5:10 PM, Ruslan Zakirov ruz@bestpractical.comwrote:
Hello Wayne,
Check DateDayBeforeMonth config option in the config. If it doesn’t
help then file a bug report.
On Wed, May 18, 2011 at 12:42 AM, Wayne Thursby wayne.thursby@hcmeinc.com 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.
–
Best regards, Ruslan.