Datepicker: 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/

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.

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.

Replying to [comment:3 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.

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.

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.