Opened 13 years ago

Closed 11 years ago

Last modified 8 years ago

#1872 closed enhancement (duplicate)

TimeDatePicker: implement widget for selecting date and time

Reported by: Eugene Lazutkin Owned by: haysmark
Priority: high Milestone: 1.3
Component: Dijit - Form Version: 0.9
Keywords: Cc: Nathan Toone
Blocked By: Blocking:

Description (last modified by Nathan Toone)

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.)

Change History (19)

comment:1 Changed 13 years ago by Eugene Lazutkin

Component: GeneralWidgets
Description: modified (diff)
Owner: changed from anonymous to bill

comment:2 Changed 13 years ago by Eugene Lazutkin

Description: modified (diff)

comment:3 Changed 12 years ago by Adam Peller

Component: WidgetsDijit
Milestone: 0.91.0

See also #599

comment:4 Changed 12 years ago by Adam Peller

Owner: changed from bill to haysmark

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??

comment:5 Changed 12 years ago by 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).

comment:6 Changed 12 years ago by Eugene Lazutkin

Description: modified (diff)

comment:7 Changed 12 years ago by Eugene Lazutkin

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

comment:8 Changed 12 years ago by bill

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

comment:9 Changed 12 years ago by Eugene Lazutkin

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.

comment:10 Changed 12 years ago by 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.

comment:11 Changed 12 years ago by Adam Peller

Eugene, at least the ISO serialized representation part (Zulu vs. local time, combining date and time, etc.) ought to be trivial with the 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)

comment:12 Changed 12 years ago by Eugene Lazutkin

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.

comment:13 Changed 12 years ago by bill

Summary: Merge TimePicker and DatePicker functionalityTimeDatePicker: implement widget for selecting date and time

comment:14 Changed 12 years ago by Adam Peller

Milestone: 1.02.0

comment:15 Changed 11 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:16 Changed 11 years ago by nathan

Cc: nathan added

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?

comment:17 Changed 11 years ago by Nathan Toone

Cc: Nathan Toone added; nathan removed
Description: modified (diff)

comment:18 Changed 11 years ago by bill

Resolution: duplicate
Status: newclosed

Closing in favor of #7946 which has a patch.

comment:19 Changed 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.