DOB displayed format in account edit.

[piloujp]

In account edit form, dob is displayed in 'Y-m-d' format whatever setting is done in language file.
Looking at 'header.php' file code, line 212, there is an explanation:

  // Posted page content is not requested to be processed, populate dob with customer's database entry.
  // Using ISO-8601 format of date display to support javascript/jQuery driven date picker data handling.
   $dob = zen_date_raw(zen_date_short($account->fields['customers_dob']));
  $dob = substr($dob, 0, 4) . '-' . substr($dob, 4, 2) . '-' . substr($dob, 6, 2);

It refers to some JavaScript date picker, but there is none here... Does somebody know why it is done like that, instead of just displaying dob using short date format set in language files? Is it to accommodate some plugin?

[drbyte]

I'm pretty sure we made it use ISO-8601 in order to have browsers recognize the date more consistently, especially if people opted to change the field from just a text-input to being a date-input field where the browser would render a date-picker, whether that date-picker was from the browser's internal abilities or from a 3rd party javascript tool.
It seemed to be the best way to make it as cross-browser compatible as possible, considering that every browser vendor has done dates differently.

It's a difficult situation to solve when trying to balance UX vs DX. From a dev perspective a date-picker actually makes it easier because we can force the user to provide the date via the picker's rules that guide the user through choosing the individual date segments, so we never end up with invalid or unparseable data. BUT the typical end-user doesn't usually want a date-picker when providing their date-of-birth because they have to scroll back dozens of years, where it would be faster to simply type in the year and date. (Granted, in contrast to DOB, they may not mind a date-picker so much if they're being asked to choose an upcoming or very recent date.)

[drbyte]

Having said all that, you may find that if you change the input field to a date field (to have the browser show a date-picker) instead of defaulting to a text field, it may solve whatever challenges you're facing.

-<?php echo zen_draw_input_field('dob', zen_date_short($account->fields['customers_dob']), 'id="dob" placeholder="' . ENTRY_DATE_OF_BIRTH_TEXT . '"' . (ACCOUNT_DOB == 'true' && (int)ENTRY_DOB_MIN_LENGTH != 0 ? ' required' : '')); ?>
+<?php echo zen_draw_input_field('dob', zen_date_short($account->fields['customers_dob']), 'id="dob" placeholder="' . ENTRY_DATE_OF_BIRTH_TEXT . '"' . (ACCOUNT_DOB == 'true' && (int)ENTRY_DOB_MIN_LENGTH != 0 ? ' required' : ''), 'date'); ?>

[piloujp]

Thank you for this detailed explanation, now I understand why this code is there. My 'challenge' was just to display date in proper format according to user's language choice.
I took time to change the input field to a date field as you suggested and did some testing with different browsers: Firefox, Brave and Edge on Windows 11 and Brave and Safari on iPhone iOS 15.8.1.
Well, on iPhone, dates displayed in field stay in ISO format whatever, but date-picker uses same language as browser.
On Windows 11, in Firefox and Brave everything follows the browser's language, but in Edge, displayed format and date-picker language are as system settings.
As a user, a date-picker is useful on a smartphone, but benefits are out weighted by ISO format displayed whatever page or browser settings and like you said for a date-of-birth field, if you have to slide down dozens of years... You are better without it!
All that remembered me of the hell of JavaScript Browser compatibility between I.E. and Netscape... Which was best solved with .... PHP!

All that said, displaying ISO date in this field does not make much sense as anyway, ZC templates and even bootstrap template do not set this field as a date field. The only thing it does is preventing displaying date correctly, confusing user.
Is this not some left over experimental code?

[drbyte]

Is this not some left over experimental code?

Not as far as I recall.

[drbyte]

ZC templates and even bootstrap template do not set this field as a date field

That's easily changed within your template, if you desire to do that. Simply adding the , 'date' parameter will cause both templates to invoke the available date-pickers.

[drbyte]

In the case when the field is treated as a text-only input field, how do you propose a non-standards input format be handled?

In this account-edit page, this is not merely "displayed" information: it's an edit form, and the field must both display and allow editing of whatever data is supplied to it.

So if you display and tell the customer to enter the date in some other format, you will need to tell Zen Cart how to parse that data in a way that can then be correctly stored into the database in a recognizable date format ... both to prevent the database from rejecting an invalid date, and to prevent the stored date from being misunderstood upon subsequent retrieval.

[drbyte]

Hmmm ... the Admin has some datepicker functions. They're built for the jQueryUI datepicker used in the Admin, but perhaps they may be useful catalog-side as tools to aid in the conversion back-and-forth for the few dates used there?
It leverages DateTime::createFromFormat().

[piloujp]

In the case when the field is treated as a text-only input field, how do you propose a non-standards input format be handled?

Considering dob field does not need date-picker I test some code that, for now, is doing well.
In 'includes\modules\pages\account_edit\header_php.php',
I replaced lines 57 to 64 by:
if (strlen($dob) >10 || validDate($dob) === false) {
And replaced lines 184 to 187 by:
$dob = zen_date_short($account->fields['customers_dob']);

Function 'validDate' can be placed in 'functions_dates.php' or an extra file. Code is here:

function validDate($date, $format = DATE_FORMAT)
{
	//Validate date using DATE_FORMAT as reference format. Accepts separators / or -.
	$format0 = str_replace('-', '/', $format);
	$format1 = str_replace('/', '-', $format);
        $d0 = DateTime::createFromFormat($format0, $date);
        $d1 = DateTime::createFromFormat($format1, $date);
        return ($d0 && $d0->format($format0) == $date) || ($d1 && $d1->format($format1) == $date);
}

This provides a good date validation and does not make any trouble when date needs to be saved in database.

[piloujp]

I improved this validation to accept date with /, - or nothing as a separator.
For example, if DATE_FORMAT is 'm/d/Y', then dates like these will be accepted: 03/08/2024, 03-08-2024 and 03082024.
I had to modify zen_date_raw function.
By the way there is another bug in this function when date is zero and not using English date format.

I made a GitHub branch on my repo. It will be easier to look at the code.
So far so good, I can't make it fail even in different languages.

[piloujp]

I forgot, to validate dates with number only, no separator, setting in Admin 'Configurations\Minimum Values\Date of Birth' must be changed from 10 to 8.

[drbyte]

I'm in agreement with your proposed code changes.
I made some comments in your repo branch.