228868 - Date edit-field handling weak; displays, and expects, unconventional format

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Mike Cowperthwaite]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Also present in 1.5 Final.

Create a date-based rule.  Under 1.5, when the 'Date' header is selected, 
Mozilla prefills the value field with the current date; under 1.6b, the value 
field is left blank.  The initial date shown, as well as the date shown for a 
pre-existing rule, is in the format:   dd-yyyy-mm   (leading zeros suppressed)

My preferred date display format is dd-mmm-yy  (where 'mmm' is a three-letter 
abbrev); this format is used by Mozilla to show dates in the threadpane, and is 
also the format that dates are saved into the msgRules.dat file.

The only date-format-specific entries I can find in my prefs.js are
mailnews.search_date_format and mailnews.search_date_separator.  (In particular, 
I don't have any of the preferences specified in bug 25177 comment 13.)

If I enter a date in any format that doesn't parse correctly as date-year-month, 
then save and re-edit the rule, it may show as NaN-NaN-NaN, or it may be an 
unusal set of numbers; for instance, 15-7-2002 is translated to 15-2073-10.

If I try to enter a month name/abbreviation in the expected Month slot, on 
re-edit it displays as NaN-NaN-NaN.  

If I exit with the "NaN" string, restart, and show the filter again, the NaN 
date is now shown as "18-24921-4".  (Saved in msgRules.dat as "23-Dec--28158".)

Once a "NaN" value has been stored, it does not appear possible to overwrite it 
in msgRules.dat -- I can edit the filter, re-edit to show the current date, but 
on saving and restoring, it continues to show as "18-24921-4".

If I enter, for instance, 07-10-03, the resulting date is 7-1910-3 = 7-Mar-1910, 
rather than the expected 7-Oct-2003 (per my order preference) or 10-Jul-2003 
(per standard American order) or 10-Jul-1903 (per standard American order plus 
lame century conversion).

Expected results:
Date displayed according to system preferences (as is done in Thread Pane);
parsing of date according to preferred order; parsing of date to intelligently 
read the month name (3-letter or full); an error message that prevents closing 
the dialog, inform me the date value is invalid (or at the very least, a warning 
that the date is invalid and, on redisplay, a text such as "<invalid date>").

I also would *like* to see date parsing use an intelligent century conversion 
(e.g., '03' -> '2003', '85' -> '1985') -- but this is hard to do right, 
requiring a four-digit year is acceptable.

Actual results:
Bizarre date display format; same format required of date entry; month needs to 
be numeric; accepts invalid date without a peep; bizarre conversions for certain 
combinations of numbers; invalid dates stored, and then displayed as geeky 
"NaN-NaN-NaN".

Comment 1

[Mike Cowperthwaite]

Updating this to a front-end bug because I discover that the date edit field is 
handled the same in the Mark Folder Read By Date... dialog.

Comment 2

[Mike Cowperthwaite]

(In reply to comment #0)
> The initial date shown, as well as the date shown for a 
> pre-existing rule, is in the format:   dd-yyyy-mm   (leading zeros suppressed)
> 
> My preferred date display format is dd-mmm-yy  (where 'mmm' is a three-letter 
> abbrev)

This is bug 224109.  Much of the rest of this bug may still apply, once that 
format-parsing order problem is fixed; in particular, being able to parse 
alphabetic months is still a desirable feature for date editing.

Comment 3

[Mike Cowperthwaite]

Checked this on a Win98 machine and it exists there as well.  I don't know to 
what extent this problem might apply to Mac, Linux, etc.

Comment 4

[Wayne Mery (:wsmwk)]

Does this impact bug 386334?
Should bug 224109 also be OS=ALL?

Comment 5

[Mike Cowperthwaite]

I doubt this affects 386334; display is already being performed correctly, as far as I know.

I imagine 224109 is all platforms, but haven't investigated.