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

NEW
Unassigned

Status

15 years ago
10 years ago

People

(Reporter: mcow, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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".
(Reporter)

Comment 1

15 years ago
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
(Reporter)

Comment 2

14 years ago
(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
(Reporter)

Comment 3

14 years ago
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
Product: Browser → Seamonkey

Updated

14 years ago
Assignee: sspitzer → mail

Updated

12 years ago
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

Comment 4

11 years ago
Does this impact bug 386334?
Should bug 224109 also be OS=ALL?
(Reporter)

Comment 5

11 years ago
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.
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.