Sync end date with start date

Great!.... one other thought thought (Sorry, I guess I like being the devil's advocate :-)

developer-x's Date Tweaks module does something similar for the D6 version of Date.
-Maintains the date's duration - so when the start date changes, the end date also changes.
I like that functionality, but I can understand the concern about end date unexpectedly changing when the start date is changed.
But, I think the date's duration should be maintained in 99% of all use cases, like google calendar (and majority rules).

Also, (and this might not be the place and time for this), but I have thought allowing the end date to remain blank or null (which date module does not right now).... I am rethinking that idea, but perhaps we should not lock ourselves in one way or the other.... see #874322: To Date & All Day Date Handling.
Edit: I thought about this a little more, and I think we CAN keep the end date as is (requires to be filled... if not filled it is automatically stored with the start date. So, I think that part of the patch can remain as is. But, I still think it would be nice to always maintain duration when editing the start date.

If we are adding code to maintain the date duration would it be possible to maintain the time duration as well? E.g. when the start time is updated the end time is updated to the same duration later than the new start time. Again, similar to developer-x's Date Tweaks Module. I think this would be a major usability win. Thanks

Yes, I agree with #3. That was my intention in #2. When I said date, I should have specified date & time.
This is how the date tweaks module works.

I like this conceptually, some observations:

- It has no effect on text widgets or date popup widgets. It seems like we would want to do the same thing there?
- If you have a select widget that has text elements (drop downs for everything but year and a text box for year, a combination I use often to not constrain the year), the dropdown elements change to match the from date but the year remains empty.

Can we make this effect work in textfields too?

I think I agree with the idea of maintaining the duration if the start date changes, but that can certainly be a separate issue.

The above patch no longer applied, so here is a reroll. This does not yet address any of the other feedback above, though.

The original patch description in this issue states:

On page load, it makes the end date the same as the start date.

This behavior actually leads to a number of bugs. For example, if the default value for the end date is supposed to be different from the start date, the patches above would clobber that and force them to be synchronized. Similarly, if you get a form validation error while trying to create content (e.g. leave the node title blank), then when the page reloads with validation errors the end date you previously entered will be erased and set back to the start date.

Those issues should be fixed in the attached version.

I also fixed a couple other smaller things:

• The JavaScript code for hiding $('.js-hide') wasn't necessary (Drupal core already does that), so I removed it.
• The date.js file was provided by the Date module but being included by the Date API module, which isn't correct (Date API doesn't depend on Date). This also resulted in the file being loaded sometimes when the date combo widget wasn't being used. That's fixed in the attached, which makes Date module load its own file. (For now, I'm only loading the JS file when a select widget is being used because that's the only place it works, but that may change if we address other feedback in this issue and get it working for textfields. Similarly, the patch hides the fieldset description for JS users using "js-hide" even in cases where a select widget isn't used and thus where the end date isn't synced and is allowed to start off blank, but that problem would also go away if we eventually make it work for textfields.)

Still leaving this at "needs work" for the remaining issues.

So the fix for initially blank end dates is to hide the message that says what it is rather than to make it work? I guess if javascript is enabled having the end date auto-adjust to the start date might be ok, but without javascript they won't see the message so won't get the benefit of not having to fill in every part of the date, right? I guess we could get rid of the functionality that tries to auto-compute blank end date parts by filling them in with the start date, which would simplify the code somewhat. Then you have a nice feature if javascript is turned on, otherwise you have to fill in every single date part for both the start and end date.

I'm not too worried at this point about maintaining duration, but we definitely want textfields to work the same as select fields. Especially since you can have a combination of text and dropdown fields in the same element.

One other concern we may run into. Some people are quite concerned that the user be forced to enter a value into the date field, they don't want anything auto-populated, to the extent that they want the field to be required and also empty to force the user to select a value. So we may need to make this behavior optional. Making it optional would also provide an escape for anyone who just doesn't like the way it behaves, for whatever reason. We could do something like what we're doing with the timepicker -- have a sitewide configuration for whether or not this behavior is enabled.

So the fix for initially blank end dates is to hide the message that says what it is rather than to make it work?

I think it was sort of by design in the original patch that default "blank" end dates no longer actually appear blank to JS users (given that they're treated as non-blank behind the scenes, the patch was just making that appear on the surface). But it may be confusing since it's not what the person asked for when they went to configure the field. Which gets at the question you asked about some people wanting to turn off this behavior.

I guess we could get rid of the functionality that tries to auto-compute blank end date parts by filling them in with the start date, which would simplify the code somewhat. Then you have a nice feature if javascript is turned on, otherwise you have to fill in every single date part for both the start and end date.

I think we can actually meet all the goals here without even removing this feature for non-JS users. Maybe we can just have the JS code in the patch not run at all for initially blank fields? So the magical JS-based syncing behavior would only occur in the case where the start and end date were initially identical (which is the default behavior of Date fields after the patch).

If someone goes out of their way to choose "blank" when they create a field, then it could behave the same way as the module does now.

I guess if javascript is enabled having the end date auto-adjust to the start date might be ok, but without javascript they won't see the message so won't get the benefit of not having to fill in every part of the date, right?

In the current patch, the message is only hidden for users who have JavaScript turned on. For non-JS users, they'll still see the message.

Tagging.

This still applies and I decided it's enough to have the select dates synching, since those are the ones that are annoying to do manually. The popup and text fields are OK as-is.

I applied the patch successfully however the end date doesn't automatically sync upon setting the From Value. But if i click the text "Month" or "Day" above the field input for instance, the End Date and Time is synced. On the other hand, if I set both values to Now or Relative it works.

I would like to add that because the "Date Single Day" module is not ported to D7 I am having a lot of trouble allowing my users to simply add a From date and plug in two times on the same day. That's why I thought I could use this patch. So internally, I would hide the 'To Date' assuming it would automatically be filled in but not hide the 'To Time' allowing the user to select the single Day and From and To times.

Anyway, just making an observation. Not much anyone can do about it.. Would be nice to have more options for simple settings on Date Module -- "Add option to Select Single Date with From and To times"

Hi there. Is there any particular reason this is only applied to the select widget? We had a similar situation where we needed the end date to be at least greater than the start date (we don't have blanks in our case). Is there any fundamental reason to not include the other widgets? On that note, I've half hazardly created another JS file that applies similar functionality to the date popup widget. I haven't tackled the raw text field.

omit

If you mark it as 'Needs review' the bot will keep trying to test it.

Ah, thanks, sorry about that.

Any upgrade about this?

#16 Works well, but bare in mind that this only works with US date format.

If you are using non US format, then I suggest modifying the "Drupal.date.EndDatePopupHandler.prototype.endDateIsLess" function. I had a date format "dd.mm.yy" so I changed that part to this:

Drupal.date.EndDatePopupHandler.prototype.endDateIsLess = function () {
  return ($.datepicker.parseDate('dd.mm.yy', this.$end.val())).valueOf() - ($.datepicker.parseDate('dd.mm.yy', this.$start.val())).valueOf() < 0;
};

Of course in ideal world this script should understand the format automatically but this get's the job done.

Thank you Martin, well done

Thanks @Hazah, #16 worked great, even today. 5 years later.