Discourage/make impossible to select a "to" date that is before the "from" date

What if the user spots the need for a date change and decides to change the 'to' date first on the way to changing the 'from' date?

We could also greatly improve on that error message that is currently displayed...

I agree with making "to" dates that are before the "from" date disabled. In my opinion the likelihood of someone spotting the need for a date change and starts with the "to" date is small, and the level of inconvenience they would experience in this case is pretty insignificant. I would gladly sacrifice it for ensuring that invalid date ranges don't even make it to the server, they get caught in the browser. It's better for the user (faster feedback) and better for the site owner (less requests to handle by the server).

The other option I see is that we automatically update the "from" date when the user picks a preceding "to" date so the two dates are at least equal, but I think from a user experience standpoint automatically modifying incorrect user input is worse than preventing incorrect user input, at least in cases like this, when we don't know what to modify it to because we have no clue about what the user wants. I mean, it's pretty unlikely that the user wants to enter the same date to both fields, so this modification would be a correction for Drupal but not for the users.

Finally, the error message could be improved too. I simply suggest to remove the confusing part (that ironically the author probably meant as clarification):
"The end date cannot be before the start date"

Thanks for the input. When the field is configured for date+time, then you definitely will have people using the same date but different times. Also, it has come up where people are using the date-only flavor of the field and using the same date for start and end.

And for anyone trying to figure out a patch, we have a few complications...

- Browsers with non-HTML date/time inputs get the polyfill.
- If configured as a field, we know how the element is configured out of the box, but if we solve this at the element level (instead of the widget) and not the field, then there are some weird combinations we need to consider.

Might be taboo but how about automatically reordering the dates on the php side so it's always earlier date as 1st value + some text in the widget config to warn of the behavior? (and possibly a warning message saying dates were swapped after save)

Looking at #2 -- tricky indeed. On various datetime range inputs on my phone, for example, if I make the start date/time later than the end date/time, it automatically advances the end date/time to be the same as the start date/time. Sometimes this is helpful, and other times it's annoying because I lose my intentional input for all the end date year, month, day, and time just because I accidentally misclicked on (e.g.) one year higher than I meant for the start date.

Might be taboo but how about automatically reordering the dates on the php side so it's always earlier date as 1st value + some text in the widget config to warn of the behavior? (and possibly a warning message saying dates were swapped after save)

I do not think this is a good idea. :) Better a validation error than unexpectedly/magically trying to change saved data in this way. This could have all kinds of unexpected results.

I think part of what @yoroy was suggesting was that the widget should show you what the start date you picked was. Lots of calendar picker widgets have thingies that look like:

That's the hipmunk daterange selector widget. If I click on the start date field and click July 27, it moves the forward arrow but also blanks out the end date so I have to reselect it. But that's not what our datepicker does.

Complicated problem, for sure.

So, are we going to entertain the option of abandoning the HTML5 inputs in favor of a JS library? That could have some ripple effects into the Datetime and Timestamp widgets.

Sorry, #9 wasn't a recommendation or anything; I was just trying to illustrate different ways that different apps solve #2.

The minimum fix would probably be to dynamically set the minimum allowed end date value to the same as the start date. That way, we don't have to worry about edgecases as much, and presumably we wouldn't have to do anything special with the polyfill to support that.

I think it is worth discussing, potentially as a f/up to this. I think the native HTML5 elements are better, but the user expectations are mixed. A lot think that the popup is coming from core, but only when a browser doesn't support native HTML5 elements. We have had bunches of issues about this, and in particular the quirk with the date formats. There is a decent argument about a standard date/time picker across all browsers. But, you could also argue that this should be deferred to contrib.

The minimum fix would probably be to dynamically set the minimum allowed end date value to the same as the start date.

I think that really is the best starting point, unless there is better guidance from Google Calendar, OSX Calendar, and Outlook. We just have to remember that date+time is a compound element.

I think the general pseudo code is

start.onchange => end.min = start.value; if end.value < start.value then end.value = start.value

and we can handle this with the min attributes, maybe add a dynamic message if we bump the end value. But I'm not really sure we can really enforce the min time strictly with the attribute.

Need to track down my UI pattern books...

Here is a starting point to play with. I think the patch has the proper list of remaining work as @todos.

Added Needs manual testing for the time being, but we will eventually want JSTB test coverage.

I've tested #14 patch.

1. When user edit, he can add an end date < start date.

Steps:

Add normal dates on calendar (start date < end date) and save it
open the node for editing
change end date

Actual result:all dates are available for end date and user can select end dates < start date

Expected result: should be available only end dates >= start date

Note:if user change start date after second step, then is working as expected

2. Error message is not enough exactly, when user put the wrong time
   
   Maybe will be better:"The [field_name] end date(time) cannot be before the start date(time)" for all cases (date and time)?

#15, thanks for testing this out. That is a nice catch, and a good suggestion. We are going to handle the error messages in #2895055: Edit the date range error messages; this issue is really just about adding some client-side JS validation / handling to try to prevent a round-trip for validation.

Trying to clear out the NR queue, so bumping to NW for all the @todos and the tests.