Validate that the unpublish date is in the future

Although the issue says to check if the option is set to display an error, I couldn't find this in the D7 version of the module, so I left this out.

Corrected the summary which had some copy/paste accidental extra info regarding an option. This was only applicable for the publish-on field.
Also removed the note about this issue being postponed, that was just wrong (and the issue was not postponed anyway). Work can be done on this issue - the patch will need re-rolling, though.

Here's a re-rolled patch. Same basic coding as before.
If the patched code is tested then we should get a clean set of passes for testSchedulerPastDates() as the code is working fine in manual testing, local simpletest runs and via run-tests.sh

Looks like the patches are still not being applied (or maybe I am doing something wrong? although I have been following the same operations as were sucessful before).

On the test results console I noticed:

08:18:35 Fetch of https://www.drupal.org/files/issues/2490576-6_validate_unpublish_date_is_in_future.patch to /var/lib/drupalci/web/jenkins-default-50419/sites/all/modules/scheduler/2490576-6_validate_unpublish_date_is_in_future.patch complete.
08:18:35 Completed setup:fetch
08:18:35 Executing setup:patch
08:18:35 Entering setup_patch().
08:18:35 Patch /var/lib/drupalci/web/jenkins-default-50419/sites/all/modules/scheduler/2490576-6_validate_unpublish_date_is_in_future.patch applied to directory /var/lib/drupalci/web/jenkins-default-50419/sites/all/modules/scheduler
08:18:36 Completed setup:patch

It might be nothing, but it seems odd to me that the message says it has applied the patch to /sites/all/modules/scheduler when that is the 7.x directory path. in 8.x it should be /modules directly under the root. Maybe the testing servers do things differently, but this looks wrong to me. Does anyone have any other ideass about how we can resolve this?

Well, actually it has changed on DrupalCI in the last week or so. On 4th December it was running Drupal 8.0 and the folder was just /modules. But by 15th December it was running 8.1 and the folder was /sites/all/modules. However the directory that the tests were run from appeared to be /modules in both cases. I've attached a comparison on the console logs with the timestamp set to zero and id set to NNNNN so that it shows actual differences. This is only part of the log but it does seem not quite right.

I have also re-queued an old patch which should definitely fail to apply and the test ran without any error.

It is not just me! There really is a problem #2634114: Patches not applied correctly for contrib modules, PHP >= 5.4?

Now that DrupalCI patches are being applied again I re-queued the patch in #6. We now get a clean set for testSchedulerPastDates as expected.

✓		- testSchedulerPastDates

Overall we get 9 test classes passes and 7 fails.

Thanks Joe for the original patch.
Now we are moving again.

This is fixed so setting to Unassigned