Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9497 closed feature (wontfix)

Datepicker: setDate +d/+m/+y doesnt take current value into consideration

Reported by: jammin Owned by:
Priority: minor Milestone: none
Component: ui.datepicker Version: 1.10.3
Keywords: Cc:
Blocked by: Blocking:

Description

According to the "setDate" function (http://api.jqueryui.com/datepicker/#method-setDate) "y" for years, "m" for months, "w" for weeks, "d" for days would be that it would increase it from TODAY only?

If the field has a valid value, why not take that into consideration? If it were specific to be from today, then I would think the null function of setDate be used first.

An example of my feature request/bug. http://jsfiddle.net/uKqUn/

Change History (6)

comment:1 Changed 6 years ago by tj.vantoll

Status: newopen
Summary: ui.Datepicker setdate +month doesnt take current value into considerationDatepicker: setDate +d/+m/+y doesnt take current value into consideration

I'm not sure how relevant this will be after the datepicker rewrite, but this seems like a reasonable suggestion. I would expect the method to work this way.

Simplified test case: http://jsfiddle.net/tj_vantoll/WrJSU/

comment:2 Changed 6 years ago by Scott González

Resolution: wontfix
Status: openclosed

All relative dates are from today. I'm not sure how you could use the API sanely any other way. What you really want is a general date library that will let you provide both a starting date and a relative value, returning a new date which you can then pass to setDate(). We may release a general date library during the rewrite, but this type of functionality is out of scope for the datepicker widget itself.

comment:3 Changed 6 years ago by jammin

Scott seriously? I'm glad tj at least got it.

the "starting date" is the value in the field itself. just as if i was to use 'open' or any other reasonable api within the widget it will open based upon the input field, if the field is blank then it opens using today.

so i fail to see how this is 'out of scope', could you please help me understand?

sure a date library could be beneficial for many things but if your already providing a relative +period I only see this as a logical way this api should work as supported by tj and the design of other api's within the widget.

comment:4 in reply to:  3 Changed 6 years ago by Scott González

Replying to jammin:

sure a date library could be beneficial for many things but if your already providing a relative +period I only see this as a logical way this api should work as supported by tj and the design of other api's within the widget.

Which "design of other api's within the widget" work with relative dates from a date other than today? Having the behavior of setDate() change based on whether a date is currently selected will surely just lead to bugs being filed about "incorrect behavior". Your request would also mean that if there's already a date set and you want to set a date relative to today, you'd get two change events (since you'd first have to clear the value, then set the relative date), which isn't really indicative of what's happening.

comment:5 Changed 6 years ago by jammin

your correct by saying no other api within the widget uses relative dates. but that wasn't what I was getting at.

I was trying to establish that the widget always uses the input date (written or selected) when performing the next action.

eg. setDate 20/1/09; open.

I would expect the open to be based on the value defined and not to use today.

in your final scenario i would think it less likely that your going to use setDate based upon today if you've already past onload and input has already occurred. I would think that it is more likely the user clears the input field for it to then revert back to today.

regardless thanks for considering, i look forward to future ui features.

comment:6 Changed 6 years ago by Scott González

Of course opening the datepicker is going to show the selected date. There's no other value that would make sense. If there is no date set, then the defaultDate is used, which defaults to today. Again, allowing relative dates from today.

Note: See TracTickets for help on using tickets.