305270 - add support to input date like 08192005 for 08/19/2005

Status: NEW

(Calendar :: General, enhancement)

Description

[Mike]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

It would be nice to be able to input a date in the mmddyyyy or mmddyy format and
have it be parsed into the mm/dd/yyyy format. This would be put to use when
using the "Choose Date" command or in the Event/Task editor when inputting a
Start/End Date, Repeat Until date, or Exception Date.

An example of this function can be seen in Microsoft Money 2005 (and probably
many other programs).

Reproducible: Couldn't Reproduce

Steps to Reproduce:

Comment 1

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 2

[Kumaran Santhanam]

While this is being done, it would be good if the parser could also understand dates of form:

mm/dd
m/d
m/dd
mm/d
mmdd

with an optional /yy or /yyyy suffix.

Comment 3

[Kumaran Santhanam]

Attachment: Enhanced date/time parsing in the datetimepicker field.

Comment 4

[Kumaran Santhanam]

Comment on attachment 297648 [details] [diff] [review]
Enhanced date/time parsing in the datetimepicker field.

This patch provides enhanced date/time parsing.  The parser will
understand the following formats:

mm-dd
mm-dd-yy
mm-dd-yyyy
dd-mm
dd-mm-yy
dd-mm-yyyy
yyyy-mm-dd
n
+n
-n

With the exception of the ISO format (yyyy-mm-dd), any of the 'mm' or 'dd'
can be given as 'm' or 'd'.  Instead of '-', either '/' or '.' may be
used.  The mm-dd order is determined by the existing locale code.

The last three are relative dates.  The 'n' and '+n' forms are
equivalent and simply add that number of days to the current day.
Similarly, '-n' subtracts that number of days from the current day.

Comment 5

[Kumaran Santhanam]

Attachment: Enhanced date/time format parsing.

This patch provides enhanced date/time parsing.  It obsoletes a recently submitted patch and provides the mmdd[cc[yy]] and ddmm[[cc]yy] format in addition to the other formats listed above.

Comment 6

[David Ascher (:davida)]

adding support for things like
 
today
tomorrow
Tuesday

etc.  would be great as well, although probably harder because of the l10n interface use required.

Comment 7

[Joey Minta]

(In reply to comment #6)
I added support for 'today' 'tomorrow' and 'yesterday' via a datetextpicker element that was later removed from the UI. :-(  Nonetheless, the logic/l10n issues were already solved there and should still be readily re-usable.  See bug 345998.

Comment 8

[Joey Minta]

Oh, yeah, it did "Next Tuesday" and "Last Monday" too.

Comment 9

[Kumaran Santhanam]

As a workaround for 'today' and 'tomorrow', you can use +0 and +1 (or 0 and 1).  However, I do agree that days of the week can be useful.  If that is implemented, it would be good to allow any prefix of 2 or more characters so that the entire day does not have to be typed.

I saw the language support in the code while working on it.  Unfortunately, due to some class inheritance issues, it was a bit more involved to support that also.  However, that code might be more easily moved into the new parseDateTime method.

Comment 10

[David Ascher (:davida)]

jminta: I don't know what the UI story is, but recovering the feature from the "command line" POV should be an easy win with relatively little UI impact.

google calendar does this stuff w/ great effect in their 'quick add' dialog.

probably should be another bug, though -- i don't mean to hijack Kumaran's patch.

Comment 11

[Christian Jansen]

Kumaran: Please remove me from code review. I'm only responsible for ui-reviews. Thanks.

Comment 12

[Stefan Sitter [:ssitter]]

The datetextpicker is still waiting to be fixed and added back to the application. See also Bug 374080.

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

How does this patch decide between ddmmyyyy and mmddyyyy? This is a quite locale specific requirement, I think this should be handled using locale strings or better yet the operating system date format.

Comment 14

[Kumaran Santhanam]

(In reply to comment #13)
> How does this patch decide between ddmmyyyy and mmddyyyy? This is a quite
> locale specific requirement, I think this should be handled using locale
> strings or better yet the operating system date format.

It uses the existing locale probing code in the same file.  I did not modify that, since I don't have a good way of testing.  Therefore, if the locale detection used to work, it should work the same with this patch.

Comment 15

[:Hb]

When creating a new event the subject line should be parsed for numeric values on the right hand side. If numbers are found, they should be added relative to the active calendar date to generate the start and end dates.

I want the user interface to free me from typing in redundant data!

Most events are typed in from a list or planning sheet. Typically these events are in an ascending order on a list. Example with a DDMMYYYY date format for a nearly biweekly meeting in our office with the first occurrence on February 7th 14:00 (2:00 PM). Currently I have to type in:

SUBJECT [Tab] [Tab] [Tab] 7/2/8 [Tab] 14 [Enter]         (11 Keys w/o SUBJECT)
SUBJECT2 [Tab] [Tab] [Tab] 21/2/8 [Tab] 15 [Enter]
SUBJECT3 [Tab] [Tab] [Tab] 6/3/8 [Tab] 1430 [Tab] [Tab] 1730 [Enter]

I'd like to type:

SUBJECT [Space] 7.14 [Enter]                    (5 Keystrokes without SUBJECT)

The active date jumps to February 7th. For the next meeting I type:

SUBJECT2 [Space] 21.15 [Enter]

The third meeting on March 6th 14:30 (2:30 PM) lasts 2 hours:

SUBJECT3 [Space] 6.143-163 [Enter]


The subject field should be processed in this way:

1. Test if the last character of the subject is numeric or like "AM" or "PM".

2. Test if the first n characters of the subject are nonnumeric.

3. Test if a space exists between the words on left side and the numeric cluster on the right side.

4. Test if numeric cluster has a decimal sign in it. 
   No decimal sign = All day event, treat the whole cluster as date part
   Decimal sign but no more chars = Same times as last event
   Decimal sign = Treat the following as time part
   
5. The date part should be processed like:
   1 numchar = Day
   2 numchars = Day Day
   3 numchars = Day Month Month
   4 numchars = Day Day Month Month
   6 numchars = Day Day Month Month Year Year
   8 numchars = Day Day Month Month Year Year Year Year
   5, 7 and more numchars = invalid
   (? 1-2 numchars, separator, 1-2 numchars= Day Separator Month)

"Day" means the next date with this day value seen from the active calendar date, not from today. A relative declaration like "+2" may be useful.

6. The time part should be processed like:
   1 numchar = Hour
   2 numchars = Hour Hour
   3 numchars = Hour Hour Tenth of Minutes
   4 numchars = Hour Hour Tenth_of_Minutes Single_Minutes

If the time part has a "-" separator the following part should be treated as absolute end time. If the separator is "+" the following part should be treated as relative end time.

Comment 16

[Martin Schröder [:mschroeder]]

Comment on attachment 297652 [details] [diff] [review]
Enhanced date/time format parsing.

Changing reviewer to Daniel. Christian does ui-reviews only.

Comment 18

[Berend Cornelius]

patch works fine and looks good at first sight.
Yet I am sorry I have to deny the review at first as the error console throws many warnings that should be worked in beforehand.

Comment 19

[Berend Cornelius]

Comment on attachment 297652 [details] [diff] [review]
Enhanced date/time format parsing.

denying review due to previous comment

Comment 20

[Berend Cornelius]

Comment on attachment 297652 [details] [diff] [review]
Enhanced date/time format parsing.

Sorry, I am only the review but not the ui-reviewer

Comment 21

[Stefan Sitter [:ssitter]]

The new parser implementation fails on the date format as used in Germany. If I enter e.g. "24.12.2008" it will be parsed to "12.12.2009". This works in the current implementation. Such a regression is not acceptable because Sunbird should work correctly on all supported platforms and their date format.

Comment 24

[Christian Jansen]

Comment on attachment 297652 [details] [diff] [review]
Enhanced date/time format parsing.

I'll minus this review, because of the bug mentioned in Comment #21.