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

[lat9]

The processing might be a bit more complex, since a phone-owner can change the format of the date/time display (see this link, for example).

I don't know how (or if) that display-setting affects the date-format returned.

Update: For an <input type="date" /> control, the value returned is always yyyy-mm-dd.

[mc12345678]

The processing might be a bit more complex, since a phone-owner can change the format of the date/time display (see this link, for example).

I don't know how (or if) that display-setting affects the date-format returned.

Update: For an <input type="date" /> control, the value returned is always yyyy-mm-dd.

Update part is good to know. I did also try to modify my mobile device (successfully) and although my active GPS changed to km, the result was the same of the date being in the iso format described above.

Still other issue is a standard for converting iso style date formats to a date format acceptable to zen_raw_date or where such device date can be received, that something be done to directly manipulate the iso formatted date to the needed raw date...

[wonged]

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.

Well, our web store requires that customers be 18 or over. Also now that the store is selling old issues of PB magazine, we feel we need to collect the Date of Birth to "validate" that the customer is over 18.

[DrByte]

mc12345678 has given lots of suitable ways to approach the matter.

[mc12345678]

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 (-).

Finally, with a little more thought and review, although not strictly checking that the date is provided as ISO-8601, it is provided/checked to a format considered acceptable by the strtotime function as relates to ISO-8601. If wish to limit the date format to just dashes between values of importance then change (|-|\/) to (-):

  if (ACCOUNT_DOB == 'true') {
    if (ENTRY_DOB_MIN_LENGTH > 0 or !empty($_POST['dob'])) {
      if (preg_match('/^([0-9]{4})(|-|\/)([0-9]{2})\2([0-9]{2})$/', $dob)) {
          $_POST['dob'] = date(DATE_FORMAT, strtotime($dob));
          $dob = date(DATE_FORMAT, strtotime($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);
      }
    }
  }

This is expected to convert an ISO 9601 styled date (or at least what the php manual for the date format function indicates is acceptable and still to be an ISO 9601 related style date) and relatively respect the language settings for the date format. Date formats that could be either entered at the date field (manually) or as provided by the browser from a date selector and be executed in the new section of code above would be: YYYYMMDD, YYYY-MM-DD, or YYYY/MM/DD (the first of which is pretty much already a raw date, but this let's ZC deal with that). There may still be a further improved correction. This targeted just the date check area and not the overall process. What this also means though is that dates if entered in any of these formats will be evaluated to at least discredit dates that don't exist if the MM and DD are switched where the true/intended DD is greater or equal to 13 as well as for those dates entered that exceed the calendar day of the given month.