TimeDatePicker: implement widget for selecting date and time

[elazutkin]

It rarely makes sense to select time without date. E.g., any kind of event selection/scheduling requires both date and time components. We need to merge DatePicker with TimePicker. A parameter should be used to specify if we want to see a date selector, a time selector, or both.

(I had preliminary talks with Karl on that off the list.)

[peller]

See also #599

[peller]

Mark, perhaps if we make a composite popup with a _Calendar and a _TimePicker and used it as the _popupClass, we could create a DateTimeTextbox??

[bill]

Note that this would require you to *not* close the popup on click, since you have to click multiple times to select a date & time. Not sure how things would work. Have to think about this one before implementing (and to make sure we even want it as part of dijit).

[elazutkin]

Most probably it should simulate a dialog (a modeless dialog?) and have an explicit "Set" or "Apply" button.

[bill]

One question is, why is this better than just having a DateTextBox? and TimeTextBox? next to each other? That's how sites like www.expedia.com work.

[elazutkin]

I don't think it is important. I wrote my share of scheduling applications and typically I ended up saving date+time together in some standard format (ISO 8601 is the clear favorite). It required extra code to do it client-side (which broke the simplicity of the form submission), or server-side (which opened a possibility of mistakes by less competent programmers). In both cases it was not very pleasant experience.

Additionally there were some complexities with time zones --- typically all time/date-related stuff is kept server-side in GMT, and you have to split it and convert it to the user's TZ. The more controls you have, the more work you do, the more change to make a mistake.

Not really related to the ticket, but one important case is to create recurrent events. All stuff I saw or did implemented cron or iCal or both. cron is relatively simple to implement, but not very flexible. iCal is much better for scheduling, but GUI for it are on the scale of the mini-application rather than control. Both have one thing in common: typically you have to show to the end user a list of first N occurrences, so she can see that she didn't make a mistake specifying a recurrent event. This problem was solved by calling a server to do that.

It would be nice to have a canned component to do recurrent events, but given the complexity and the scope, it looks like a candidate for DojoX.

[bill]

I can see how that would be annoying to have to do that combination in user code.

Alternately to having one big drop down with an "apply" button, we could have a single TimeDatePicker? widget that's displayed (visually) as two <input>s with two drop downs, but that submits with the form as a single value.

[peller]

Eugene, at least the ISO serialized representation part (Zulu vs. local time, combining date and time, etc.) ought to be trivial with the dojo.date library and essentially encapsulated from the user by these widgets already. I figured this is exactly why we might want a single widget, or at least a single abstraction. The datetextbox today could be configured to validate and submit a date/time. It only lacks the ability to popup both date and time pickers (a dialog would make sense)

[elazutkin]

Good point. Basically what I am trying to say it is quite useful to have a date picker without the time part. But when you need the time you usually need the date part too. One major exception is scheduling of recurrent events, but it should be handled separately. That's why I think we have to have a widget, which can do both. I don't care if it consists of two pop-ups or one. Two pop-ups increase visual complexity, but anyway it is better than nothing at all.

[alex]

Milestone 2.0 deleted

[nathan]

I think this could be accomplished quite simply by extending the date picker a little bit. The idea being that you want to have your form return a single value for "Date and Time".

You could extend the date picker to accept an (optional) "timebox" parameter (or attribute). If the "timebox" parameter is specified, then getValue() on the date picker would return the date, plus the time....

It could look like this in HTML:

<input type="dijit.form.DateTextBox?" id="dateTime" timebox="timePicker" name="dateTime" ... /> <input type="dijit.form.TimeTextBox?" id="timePicker" ... />

Note, timebox points (by id) to another widget - similar to how the label's "for" attribute points to a widget. By not giving the time picker a name attribute, it will not be returned in a call to form.getValues().

Calling dateTime.getValue() would return the date from dateTime and the time from timePicker.

This sort of solution would only require quite minimal changes to DateTextBox? - basically just overriding getValue in the event that timebox is specified. It also allows for flexibility of positioning the elements however you wish (side-by-side, top-to-bottom, etc)

Would that sort of thing work?