Before updating to v1.37 (from 1.36) date_popup fields were correctly validated. In v1.37, no date is considered valid.

Consider a date_popup field that is created via the FAPI like this:

$form['date_donated'] = array(
    '#type' => 'date_popup',
    '#date_format' => 'm-d-Y',
    '#default_value' => date('m-d-Y H:i:s', REQUEST_TIME),
    '#required' => true,
),

No date is considered to be valid. I am using v7.x-2.6 of the Date module, of which the date_popup is a part.

Comments

Assigned:Unassigned» Jelle_S

I'll ask Jelle to have a look tomorrow

Status:Active» Fixed

Fixed in the latest dev version. The reason of the bug was that we did a parseInt() of each value (day month year) and then checked the format of the parsed value. So if the format was 01/02/2001, it would look like this after the parseInt()'s : 1/2/2013 which wasn't considered valid according to the format (missing leading zero's).

Can you confirm the fix? (wait 12 hours for d.o to sync with git or get the latest dev directly from git)
-> feel free re-open if it isn't fixed on your side

I'm using Scheduler with a date popup, and I cannot get past the validation. I have month names instead of numbers and disabling this module gets me past validation. Digging deeper at the moment.

Version:7.x-1.37» 7.x-1.x-dev

#3 Did you try the latest dev version?

Yep. I'm on 1.37+8. It turns out that using month names ("F in format string) in the date popup are not quite fixed with the latest. I have a working patch that fixes it for my use case, but I am not sure that it doesn't break any other use cases.

Oops, forgot the patch. Here you go. I'm guessing it could use a little massaging to be more general, but it addresses the monthpos == false problem with "F" in the format string.

Status:Fixed» Active

+++ b/clientside_validation.jsundefined
@@ -1179,15 +1179,24 @@
+            date = new Date(parts[param.monthpos] + " 1, 2000");

We need a way to support multi lingual sites, so we need to know the right strings from the PHP side, so they can be used on the javascript side. This line will pass the input directly to Date and isn't probably going to work in all languages.

Is this as simple as using Drupal.t in JS? Or is there more to it?

#1886424: Date validation fails when text is used instead of numbers added Drupal.settings.clientside_validation_settings[] added a mapping from month names and abbreviations to month number, but I didn't had the time to test it

I followed the design pattern in #1886424: Date validation fails when text is used instead of numbers, so if it works there, it should work here. I didn't have time to test multilingual either, but I assumed mapping a month names from different languages would "just work" and produce the correct number. IF that is not the case, then we have a new can of worms.

Here is an updated version that works with both full and abbreviated month names in the format string. I also had a problem with February dates that was a brain breaker. It turns out that setting the day, then month, then year (as opposed to the opposite order) fixes February-based validation errors. This seems to be due to the offset numerical days in February, I have a hunch this is related (or the re-ordering might even solve) #1902840: Date validation fails when days overflow..

I have not tested multilingual month names in this version.

@mpgeek
Setting the Day, then Month, then Year will fix the issue that happened when the current Day is 30 or 31 - any Month, and you try to validate a February date. But now the Month is February, so try to validate a date with any Month, where the Day is 30 or 31, using your version with the changed orders. Please look again at http://drupal.org/node/1902840, I updated it for greater clarity.

Hi all,

As expecting the new dateFormat validation function from -dev works properly. Because I don't want to use a dev version on my website and can't find a patch containing only the new validation function (sorry if I missed that) I create a quick patch to replace 1.37 function by -dev one.

The patch in #11 didn't fully apply to the latest dev version. Let me see about re-rolling.

Does this patch fix the issue with the scheduler module "The value in Date is not a valid date."?

Status:Active» Needs work

@webdrips Did you get a chance the reroll yet?

Sorry totally forgot...this reroll of #11 seems to work with the latest dev.

The patch doesn't seem to apply, can you make sure you have the latest version from git? And can you generate the patch form within the clientside_validation module's folder? Also could you remove the trailing spaces. Besides that, patch looks good.

Okay but now not sure of the first couple changes; let me know and I'll remove them if needed.

+++ b/clientside_validation.jsundefined
@@ -704,7 +704,7 @@
         // @TODO: check settings
-        $(".clientside-error ul li").each(function(){
+        $("div.messages.error ul li").each(function(){

+++ b/clientside_validation.jsundefined
@@ -713,7 +713,7 @@
         if(visibles < 1){
-          $(".clientside-error").hide();
+          $("div.messages.error").hide();

+++ b/clientside_validation.jsundefined
@@ -899,7 +899,7 @@
             var reg = param.expressions[i];
-            var delim = reg.lastIndexOf(reg.charAt(0));
+            var delim = reg.lastIndexOf(reg[0]);

These changes would revert previous commits so they should be removed from the patch.

Hopefully third time's a charm...sorry I should have just re-rolled the patch when I said I would.

Hi there,

I had trouble with validation of dates, and was very happy to discover that it seems to work with the dev version (tested on my test environment). However I feel that it is a bit shaky to use the dev version live. Is there any plans for when next version is going to be released?

I have the same problem as well. When I use February month in field with date popup it says the value in date is not a valid date. Other months work well. Should I use dev, wait for release or hack it?

Status:Needs work» Fixed

Patch from #20 committed. Sorry it took so long.

I'm doing my best to clean up the issue queue. This fix will be in the next release.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.