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".
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.
Component: Filters → Mail Window Front End
Summary: Filter date value handling weak; displays, and expects, unconventional format → Date edit-field handling weak; displays, and expects, unconventional format
(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.
Depends on: 224109
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.
OS: Windows 2000 → Windows 98
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
OS: Windows 98 → All
Product: Mozilla Application Suite → Core
QA Contact: laurel → backend
Hardware: PC → All
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.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.