Closed pine3ree closed 1 year ago
Slamdunk
commented
1 year ago I didn't know about date formatting resulting in non-numbers :open_mouth:
I'd say you have more knowledge about this topic than me: may you open a PR with related new tests, and see if all other tests still pass?
pine3ree
commented
1 year ago @Slamdunk I didn't know, or suspected, either (been using php since 2001 :smile: ). I always assumed that hours, minutes and seconds formatting options could only result in non-zerofilled and zerofilled int strings. At first I thought that the IntlDateFormatter was being used just for symmetry with the label (array value) formatter, to have a more elegant/consistent code. Curiosity made me try it with all avaiable locales... I haven't used selects for date/time inputs in years, but while creating a Plates extensions for laminas-form, I had to examine laminas-form-view-helpers related code more thoroughly. There is also another inconsistency. The year select element has both numeric keys (select-option-values) and values (select-option-labels). It should have intl-formatted values values.
There is only one test checking the formatted selects in es_CL. We would need tests checking that all the <option value=""> parts only contain 2 or 4 digits strings and no other chars, allowing the presented label to be locale-formatted
<?php
// INSTALL libs
// $ composer require laminas/laminas-form
// $ composer require laminas/laminas-i18n
// $ composer require laminas/laminas-view
use Laminas\Form\ConfigProvider;
use Laminas\Form\Element\DateTimeSelect;
use Laminas\Form\View\Helper\FormDateTimeSelect;
use Laminas\View\Renderer\PhpRenderer;
$locale = 'ar';
//Locale::setDefault($locale);
//setlocale(LC_ALL, $locale);
ini_set('display_errors', 'true');
$__dir = __DIR__;
require "{$__dir}/vendor/autoload.php";
$view = new PhpRenderer();
$helperPluginManager = $view->getHelperPluginManager();
$viewHelperConfig = (new ConfigProvider())->getViewHelperConfig();
$helperPluginManager->configure($viewHelperConfig);
$view->setHelperPluginManager($helperPluginManager);
$formDateTimeSelect = new FormDateTimeSelect();
$formDateTimeSelect->setView($view);
$datetimeField = new DateTimeSelect('createdAt');
$html = $formDateTimeSelect(
$datetimeField,
IntlDateFormatter::LONG,
IntlDateFormatter::LONG,
$locale
);
die("\n{$html}\n");Hello @Slamdunk ,
should I prepare a pull-request for this? kind regards
PS
We can use a simple sprintf or , since we already have a DateTimeInterface instance, just use the non-localized formatter:
Example for days select-option
protected function getDaysOptions($pattern, string $locale, int $dateType): array
{
$dateFormatter = new IntlDateFormatter($locale, $dateType, IntlDateFormatter::NONE, null, null, $pattern);
$date = new DateTime('1970-01-01');
$result = [];
for ($day = 1; $day <= 31; $day++) {
$key = sprintf('%02d', $day); // 1
$key = $date->format('d'); // 2
$value = $dateFormatter->format($date->getTimestamp());
$result[$key] = $value;
$date->modify('+1 day');
}
return $result;
}
I have a doubt about using IntlDateFormatter for options keys generations in Date//DateTime Select view helpers. The patterns used are:
At first sight one would think that all thos values are zerofilled integer strings, which could be fetched via a simple:
But testing it with various locales we get non numeric symbols. Example:
but in
DateTimeSelectelement ,for instance,setValue()is usingDateTimeSelect::format()which is not (multi-)locale aware, so it always output zerofilled int string. So setting a value after a form submission with errors will not set the posted values into the select components.Shouldn't we use
sprintffor keys ( (select-option values)) and intl-date-formatter for values (select-option labels)? ...or am I totally missing something very obvious?kind regards.