New DatePicker component

[Animal]

I thought I'd get the ball rolling with a few suggestions.

Here is what my version looks like. Bit pedestrian and "Windows V3.1" I know:

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/Calendar/cal1.jpg

The features I like are:

* Configurable minDate and maxDate
* Settable first day of week. The US standard is Sunday. ISO says Monday.
* Weekends have a different CSS class (red)
* Current date is given a CSS class (red border)
* Unavailable dates (ie before minDate and after maxDate) are given a CSS class (greyed out)
* Keyboard navigation up/down/left/right move by day, PageUp/PageDown move by month
* It won't navigate to months which are entirely outside the allowed date range

Clicking on the month name lets you change month quickly:

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/Calendar/cal2.jpg

Clicking on the year lest you set the year:

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/Calendar/cal3.jpg

Tooltip/Title appears:

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/Calendar/cal4.jpg

Features that I'd like to see:

* Being able to select a date range. Perhaps click and shift-click could select a range. So the pictured example, of selecting shipments by booking date range would only need one popup, and a range could be selected which would be highlighted. You could navigate month-to-month and see a swathe of selected dates to see you had your range as you wanted it.

* Being able to optionally specify that a time be included in the input. In our old system we have a lot of "Date of XXXXX", "Time of XXXX" prompts, for eg vessel departure date and time. What is really required is a DateTime input widget which collects the data, and offers the result in ISO format: YYYY-MM-DDTHH:MM[:SS]

* Tie the control to a text field from which the initially selected values (including a range) would be drawn, and into which, a formatted result is placed on selection. Configurable display format. Tie it to a hidden field into which the ISO formatted result is placed. I don't want my servlet authors parsing any datetime strings except ISO format.

* Pluggable parsing of values from the tied display input field. Europeans use different date orders, but different apps also use different rules. We are VERY flexible in our date input parsing. We have a fixed (in the user config) element order, but after that it's super-flexible allowing elements to be omitted and defaulting missing elements to today's values. So if the user inputs in DMY order, the following inputs are valid:

1/2/3 -> 1st Feb 2003
1/2/98 -> 1st Feb 1998 (millenium pivot year is 1970)
1// -> 1st day of current month
//-1m -> Today's date minus 1 month
12dec -> 12th of December this year (delimiters aren't needed if alpha months are used)
22.5 -> 22nd of May this year (Delimiters may be /.-\)
nm -> Next Monday
lth -> Last Thursday

And many more. So I'd like the widget to use my parsing function to pull in its initial value.

Not asking for much am I :?: :wink: :lol: :lol: :lol:

[jack.slocum]

Thanks for the input Animal. The range selection is a great idea, but I don't know if it can be done across months in an easy manner (it could be done just a lot of work).

Keyboard nav is a must. Mousewheel to cycle through months is also a must (it is currently supported and in every app I have used it in users have loved that).

The parsing is separate from the Picker and is provided on the Date object. You are well to replace the Date.parseDate code, although it is good code and really fast.

Anyway, thanks for the great unofficial "spec". I can't tell you how much that helps! :)

[rgraff]

One additional suggestion. In addition to the tie text field, having tied select boxes (month, day, year) would be nice.

[Animal]

Personally, I don't like filling in forms which have 3 separate things to click for one data item. That's a real 1990s style way of inputting dates! Clicking a 31 deep day select and scolling it to 31? No ta! Clicking a year select to select my date of birth? Being an old fart, I have to scroll for ages!

Truth be told, I, and most users who become familiar with a web app are much more likely to type a date in an abbreviated form, like I mentioned in the first post, and not bother with the popup.

I just type 17/6/62<tab> and because the control is tied to the field, it's added an onchange listener which parses the field value, and replaces it with "17-Jun-1962" because that's the format I configured it to output into the visible field. It puts "1962-06-17" into the hidden field.

If it couldn't parse it, it replaces the value with the previous value because it also adds an onfocus listener to collect the value to revert to.

[JeffHowden]

Or, you have even smarter date parsing routines that detect other formats as well:

http://jeffhowden.com/code/javascript/better_datetime_input/

This still needs some tweaks to the regular expressions, but it's still quite powerful.

[justheatingup]

Animal have you checked this out?

http://www.dynarch.com/projects/calendar/

http://www.dynarch.com/demos/jscalendar/

Mihai's js date picker is the best GNU GPL. The code might be slightly dated, but this guy is just as good as jack. I think he's on the zimbra team nowadays.

[Animal]

Animal have you checked this out?

http://www.dynarch.com/projects/calendar/

http://www.dynarch.com/demos/jscalendar/

Mihai's js date picker is the best GNU GPL. The code might be slightly dated, but this guy is just as good as jack. I think he's on the zimbra team nowadays.

I've seen that one. That's an enormous javascript file that comes with a whole lot of baggage.

It's got it's own add/remove Class methods, event handling methods, DOM manipulation methods because it tries to be standalone. It's a bit pugly too!

I think one built upon the foundations of Ext will be better.

[Animal]

Or, you have even smarter date parsing routines that detect other formats as well:

http://jeffhowden.com/code/javascript/better_datetime_input/

This still needs some tweaks to the regular expressions, but it's still quite powerful.

Ours does most of that. The "nm" for next monday. We have "fdm" for first day of month, we have "+/-n" for n days in the future/past.

I see that you have code which infers element order. I'd rather not try that - there can be ambiguities. I allow the users to specify three order types in there preferences, DMY, MDY and YMD. Within those it's totally flexible. I think users like to know here they are. Most brits will always type day month year.

[JeffHowden]

That being said, I think it should be extended to support some notion of auto-complete. It'd also be nice if it had key handlers for up/down that cycled through the date/time (first slowly and then in increments like standard spinner control inputs).

[justheatingup]

animal you alluded to something being out there to play with. this will be part of .40?

[JeffHowden]

Or, you have even smarter date parsing routines that detect other formats as well:

http://jeffhowden.com/code/javascript/better_datetime_input/

This still needs some tweaks to the regular expressions, but it's still quite powerful.

Ours does most of that. The "nm" for next monday. We have "fdm" for first day of month, we have "+/-n" for n days in the future/past.

So we're on the same wave-length then. Regardless, some built-in plain language date parsing is necessary that can be extended by the developer to handle their own unique cases. To start with though, the parsing should cover as many scenarios as possible to limit the amount of extension (if any) that's required out of the box.


I see that you have code which infers element order. I'd rather not try that - there can be ambiguities.

Yes and no. It does because for my use it wasn't so critical. I totally agree that it should be extended to support known formats. In a round-about way, it's also important that any plain language date parsing routines also have i18n taken into consideration as well.


I allow the users to specify three order types in there preferences, DMY, MDY and YMD. Within those it's totally flexible.

In an ideal world (yui-ext), I would too.


Most brits will always type day month year.

As the main effort in something like this is to make date entry as painless as possible, I totally agree that the control should cater to the preferred input format of the user.

We've also got an occassional need to know what timezone the submitted date/time is meant to be in. Perhaps that's something that can be worked into this widget somehow. Perhaps an additional control that's off by default, but can be toggled on in those instances where it's needed.

[Animal]

An optional time zone might be a good idea. In our app we certainly need to capture the time zone, but it will be inferred from a "location" input field. For example, "Vessel departure time" will be a datetime input field, and the timezone will be inferred from the "Port of loading" input field.

[radustefan]

That being said, I think it should be extended to support some notion of auto-complete. It'd also be nice if it had key handlers for up/down that cycled through the date/time (first slowly and then in increments like standard spinner control inputs).

Sorry for digging up this old discussion, but has anyone implemented up/down key handlers for the standard DatePicker component?