[Done v1.5.5.f] New customer using smartphone - Date of Birth info not accepted

[wonged]

Yesterday, I had a customer who wanted to buy something write me that she could NOT create a new account because she kept getting the message ... * Is your birth date correct? Our system requires the date in this format: MM/DD/YYYY (eg 05/21/1970). I wrote back and asked if perhaps she were leaving out the leading zeroes in the month or day ? After a couple of emails back and forth, she told me she was using a Samsung smartphone, which when she goes to enter the birth date, brings up a calendar. She scrolls through the calendar to select her birth date of 02/21/1971, but then gets the warning message, and she cant register

Looking at the php code for tpl_modules_create_account.php, I was expecting it to check that the entered date was actually formatted as xx/xx/xxxx where x was digits. But it looks like the only thing checked is the length of the entered data based on ENTRY_DOB_MIN_LENGTH. This was set to 10. So figuring that her calendar function might have been creating a date leaving-off the leading zero in '02', I changed ENTRY_DOB_MIN_LENGTH = 8. But when she tried it again, she still gets the same warning message. So because of this "bug/problem" I am losing a customer.

So my question is ... how is v1.5.5e supposed to handle Mobile Phone entries from something like the Calendar ? Anyone know what the formatted date is from the Calendar ?

Background:
storefront is at
https://www.gottahaveitnwi.com/shop/...ain_page=index
though I don't think that will help with seeing the problem ?
The store is at v 1.5.5e because I wanted the store to be mobile-friendly. Last December I upgraded it from v1.3.9h as a new install.

[mc12345678]

I don't yet have a full solution (other than modifying the html for the date of birth line to remove the type="date" portion), but I can confirm that this is an issue with at least one other mobile device.

The date is filled in to "look" like what is desired (MM/DD/YYYY); however, upon submission, the date provided is: YYYY-MM-DD which is then parsed using zen_raw_date which totally mucks up the result:
Ie put in: 07/08/1999, the posted $dob is 1999-07-08 and then the zen_raw_date result is: 7-08199- which is not exactly a valid date. Of course it also fails the '/' part, but there doesn't appear to be anything that requires the / just a divider between sets of numbers and the fact that the numbers are in two(one divider)two(one divider)four...

Looks like issue might be in: includes/templates/responsive_classic/jscript/jscript_responsive_framework.php at or around line 69:

$('input#dob').clone().attr('type','date').insertAfter('input#dob').prev().remove();

such that if that were removed, then the "phones" date chooser wouldn't appear... but at least the user could enter the birth date in the format requested...

It's a patch, not a fix.

I feel like this also might have been previously identified, though I'm not sure. Commenting out that line seems to support the date entry.

So otherwise, would need to do some other form of validation such as part of zen_date_raw to identify the existence of non-numeric values, if the values are non-numeric then perhaps use the original data formed by numbers only (as that would have been in the raw date form expected...) or in looking at the code, since the $_POST['dob'] is used, to modify $_POST['dob'] to again be the date format desired? Though I don't know how "localities" play into the javascript/jquery fed date. The test I did provided YYYY-MM-DD, but in another location could it instead provide it in another format?

Proposal is either of two things:
comment out line 69 of includes/templates/responsive_classic/jscript/jscript_responsive_framework.php:

// $('input#dob').clone().attr('type','date').insertAfter('input#dob').prev().remove();

or

in includes/modules/create_account.php
change:

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (substr_count($dob,'/') > 2 || checkdate((int)substr(zen_date_raw($dob), 4, 2), (int)substr(zen_date_raw($dob), 6, 2), (int)substr(zen_date_raw($dob), 0, 4)) == false) {
        $error = true;
        $messageStack->add('create_account', ENTRY_DATE_OF_BIRTH_ERROR);
      }
    }
  }

to something like:

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (preg_match("/^([0-9]{4})(.)([0-9]{2})(.)([0-9]{2}$)/", $dob, $output_array)) {
          $_POST['dob'] = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
          $dob = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
      }
      if (substr_count($dob,'/') > 2 || checkdate((int)substr(zen_date_raw($dob), 4, 2), (int)substr(zen_date_raw($dob), 6, 2), (int)substr(zen_date_raw($dob), 0, 4)) == false) {
        $error = true;
        $messageStack->add('create_account', ENTRY_DATE_OF_BIRTH_ERROR);
      }
    }
  }

[mc12345678]

The other option is to disable the display of the birth date if that is not at all necessary. (Fyi, if it remains enabled, but with a 0 minimum length the issue would still occur if such mobile/js date were provided.)

Perhaps there is also a way to have the date formatted within the above referenced jscript_responsive file... I haven't looked into that possibility... anyone else?

[lat9]

Remember, too, that date-formats are different in different areas of the world: mm/dd/yyyy vs dd/mm/yyyy ... both formats are recognized by the zen_date_raw function.

Is it the mobile phone's browser that's providing that yyyy-mm-dd format? If so, that's the source of the issue.

[mc12345678]

Remember, too, that date-formats are different in different areas of the world: mm/dd/yyyy vs dd/mm/yyyy ... both formats are recognized by the zen_date_raw function.

Is it the mobile phone's browser that's providing that yyyy-mm-dd format? If so, that's the source of the issue.

All testing of the observed effect was performed using results obtained by an effected mobile device attempting to submit a date using English as the language. So, yes the mobile device provided yyyy-mm-dd format upon submission. The change identified above matches the sequence that is requested of the page and of the input to zen_raw_date.

The zen_raw_date function for English expects the date in the format provided (mm/dd/yyyy).

Just downloaded the german language pack, and the same expectation exists there that zen_raw_date within the german.php language file expects mm/dd/yyyy.

The German version of say DATE_FORMAT_SHORT is in %d/%m/%Y format which is different than english.php which provides %m/%d/%Y.

But both languages expect a provided result of mm/dd/yyyy, which is/was not provided by either of these two different mobile devices manufactured by different companies and both companies operate(d) in different countries.

As such, the internal process of zen_raw_date does not appear to play a factor here, but instead what is provided to it...

[swguy]

Suggestion: Stop collecting DOB. You don't need it, and it creates a speed bump in account creation that will cause people to leave. Unless you are *required* to collect this data based on legislation, don't do it - it's none of your business.

Admin->Configuration->Customer Details->Date of Birth->false.

[lat9]

That's my point; if the mobile-phone's calendar is providing the value in the format YYYY-MM-DD then that's the source of the issue, since that format is not expected by the processing.

I've not done much with the German language, but I'll note that British, Australian and Spanish date-formats are dd/mm/yyyy.

[mc12345678]

All testing of the observed effect was performed using results obtained by an effected mobile device attempting to submit a date using English as the language. So, yes the mobile device provided yyyy-mm-dd format upon submission. The change identified above matches the sequence that is requested of the page and of the input to zen_raw_date.

The zen_raw_date function for English expects the date in the format provided (mm/dd/yyyy).

Just downloaded the german language pack, and the same expectation exists there that zen_raw_date within the german.php language file expects mm/dd/yyyy.

The German version of say DATE_FORMAT_SHORT is in %d/%m/%Y format which is different than english.php which provides %m/%d/%Y.

But both languages expect a provided result of mm/dd/yyyy, which is/was not provided by either of these two different mobile devices manufactured by different companies and both companies operate(d) in different countries.

As such, the internal process of zen_raw_date does not appear to play a factor here, but instead what is provided to it...

Though, upon further inspection, it appears that the German language pack never updated the original comment from expecting MM/DD/YYYY to DD/MM/YYYY, so yes, the above provided code would only work for languages that expect a MM/DD/YYYY format... :/ joy of trying to be sure to provide what is "expected" based on what is provided...

Changes things a bit because as said, the device is basically providing the zen_raw_date (with an extra character between each value and more than likely based on the device's local settings...)

[mc12345678]

Though, upon further inspection, it appears that the German language pack never updated the original comment from expecting MM/DD/YYYY to DD/MM/YYYY, so yes, the above provided code would only work for languages that expect a MM/DD/YYYY format... :/ joy of trying to be sure to provide what is "expected" based on what is provided...

Changes things a bit because as said, the device is basically providing the zen_raw_date (with an extra character between each value and more than likely based on the device's local settings...)

English:

////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
  if (!function_exists('zen_date_raw')) {
    function zen_date_raw($date, $reverse = false) {
      if ($reverse) {
        return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
      } else {
        return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
      }
    }
  }

German:

////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
  if (!function_exists('zen_date_raw')) {
function zen_date_raw($date, $reverse = false){
     if ($reverse){
         return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
         }else{
        return substr($date, 6, 4) . substr($date, 3, 2) . substr($date, 0, 2);
         }
    }
  }

Commenting above each version is the same; however, code below it is "different", expecting the same as described for British, Australian and Spanish date-formats of dd/mm/yyyy.

Will see what is needed to update the "thread" for the german language to point out that *minor* discrepancy.

Would also note that seems like the line:

// raw date is in format YYYYMMDD, or DDMMYYYY

For languages would make a little more sense/be a smidge more helpful with additional information:
something like:

// raw date is in format YYYYMMDD ($reverse==false), or DDMMYYYY ($reverse== true)

or default/not default:

// raw date is in format YYYYMMDD (default), or DDMMYYYY ($reverse== true)

in a true/false orientation:

// raw date is in format DDMMYYYY, or YYYYMMDD

or something...

[mc12345678]

I don't yet have a full solution (other than modifying the html for the date of birth line to remove the type="date" portion), but I can confirm that this is an issue with at least one other mobile device.

The date is filled in to "look" like what is desired (MM/DD/YYYY); however, upon submission, the date provided is: YYYY-MM-DD which is then parsed using zen_raw_date which totally mucks up the result:
Ie put in: 07/08/1999, the posted $dob is 1999-07-08 and then the zen_raw_date result is: 7-08199- which is not exactly a valid date. Of course it also fails the '/' part, but there doesn't appear to be anything that requires the / just a divider between sets of numbers and the fact that the numbers are in two(one divider)two(one divider)four...

Looks like issue might be in: includes/templates/responsive_classic/jscript/jscript_responsive_framework.php at or around line 69:

$('input#dob').clone().attr('type','date').insertAfter('input#dob').prev().remove();

such that if that were removed, then the "phones" date chooser wouldn't appear... but at least the user could enter the birth date in the format requested...

It's a patch, not a fix.

I feel like this also might have been previously identified, though I'm not sure. Commenting out that line seems to support the date entry.

So otherwise, would need to do some other form of validation such as part of zen_date_raw to identify the existence of non-numeric values, if the values are non-numeric then perhaps use the original data formed by numbers only (as that would have been in the raw date form expected...) or in looking at the code, since the $_POST['dob'] is used, to modify $_POST['dob'] to again be the date format desired? Though I don't know how "localities" play into the javascript/jquery fed date. The test I did provided YYYY-MM-DD, but in another location could it instead provide it in another format?

Proposal is either of two things:
comment out line 69 of includes/templates/responsive_classic/jscript/jscript_responsive_framework.php:

// $('input#dob').clone().attr('type','date').insertAfter('input#dob').prev().remove();

or

in includes/modules/create_account.php
change:

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (substr_count($dob,'/') > 2 || checkdate((int)substr(zen_date_raw($dob), 4, 2), (int)substr(zen_date_raw($dob), 6, 2), (int)substr(zen_date_raw($dob), 0, 4)) == false) {
        $error = true;
        $messageStack->add('create_account', ENTRY_DATE_OF_BIRTH_ERROR);
      }
    }
  }

to something like:

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (preg_match("/^([0-9]{4})(.)([0-9]{2})(.)([0-9]{2}$)/", $dob, $output_array)) {
          $_POST['dob'] = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
          $dob = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
      }
      if (substr_count($dob,'/') > 2 || checkdate((int)substr(zen_date_raw($dob), 4, 2), (int)substr(zen_date_raw($dob), 6, 2), (int)substr(zen_date_raw($dob), 0, 4)) == false) {
        $error = true;
        $messageStack->add('create_account', ENTRY_DATE_OF_BIRTH_ERROR);
      }
    }
  }

So this could be modified to be a *little* bit more "diverse" assuming that regardless of device locality that the provided result is YYYY-MM-DD:

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (DATE_FORMAT === 'm/d/Y') {
          if (preg_match("/^([0-9]{4})(.)([0-9]{2})(.)([0-9]{2}$)/", $dob, $output_array)) {
              $_POST['dob'] = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
              $dob = substr($dob, 5, 2) . '/' . substr($dob, 8, 2) . '/' . substr($dob, 0, 4);
          }
      } elseif (DATE_FORMAT === 'd/m/Y') {
          if (preg_match("/^([0-9]{4})(.)([0-9]{2})(.)([0-9]{2}$)/", $dob, $output_array)) {
              $_POST['dob'] = substr($dob, 8, 2) . '/' . substr($dob, 5, 2) . '/' . substr($dob, 0, 4);
              $dob = substr($dob, 8, 2) . '/' . substr($dob, 5, 2) . '/' . substr($dob, 0, 4);
          }
      }
      if (substr_count($dob,'/') > 2 ||  checkdate((int)substr(zen_date_raw($dob), 4, 2),  (int)substr(zen_date_raw($dob), 6, 2), (int)substr(zen_date_raw($dob),  0, 4)) == false) {
        $error = true;
        $messageStack->add('create_account', ENTRY_DATE_OF_BIRTH_ERROR);
      }
    }
  }

Although, modifications to the language(s) format would "necessitate" further update of the above logic.

It looks like the device is providing an ISO 8601 style date format which the above regex is looking at (excluding time and not requiring that the character between date numbers be a dash (-).