Example values of date inputfield are misleading!

[BernhardBaumrock]

Short description of the issue

The current date examples are misleading because it is not clear on first sight which part of the date is the MONTH and wich one is the DAY:

I've messed up day and month several times in the past years and it would really be an easy fix that prevents such mistakes that can sometimes be hard to debug and find.

I'm quite sure that 99% of the european users would read the selected value on the screenshot as "4th of August 2016" and not "8th of April 2016".

Optional: Suggestion for a possible fix

It would be better to set dates that have DAYS > 12 and YEARS > 31, eg

25.03.95
95.25.03
03.25.95

This date is unambiguous, because 95 can only be the year, therefore 25 can only be the day, therefore 03 can only be the month.

Easier examples are better readable of course:

25.03.1995
1995-03-25
1995/25/03 

[thetuningspoon]

I'm guessing this particular date is an Easter egg--perhaps the birth of someone special?

But I agree it is a bit confusing. I always have to double check one of the textual format options to make sure I've got the month and day straight.

[BernhardBaumrock]

Well I'm not against a new easteregg date that follows the mentioned restrictions. My own birth date does 🤣

[teppokoivula]

Just wanted to voice my +1 here.

Just the other day I struggled with a date field, just to realise that I had (once again) got this selection wrong. Ryan, it would be great if you could reconsider these examples – if they are indeed meaningful dates then I get that it might not be as easy as it sounds to us, but current examples are causing a bit of confusion :)

As an alternative there could perhaps be a PHP date format string, or a "human-readable" string such as "d.m.yyyy", right next to the selection? That way it would be easier to grasp.

[BernhardBaumrock]

Adding the php date format string would maybe be an even better solution!

04.08.2016 (mm.dd.yyyy)

Would then be absolutely clear on the very first glance!

[BitPoet]

Adding the php date format string would maybe be an even better solution!

Only, the formats used here aren't really nice to read. You can display them with this snippet for site/ready.php:

wire()->addHookAfter('InputfieldDatetime::getConfigInputfields', function(HooKEvent $event) {
	$inputfields = $event->return;
	
	$f = $inputfields->get('_dateInputFormat');
	foreach($f->getOptions() as $value => $label) {
		$f->replaceOption($value, $value, $label . ' [' . $value . ']');
	}
});

wire()->addHookAfter('FieldtypeDatetime::getConfigInputfields', function(HooKEvent $event) {
	$inputfields = $event->return;
	
	$f = $inputfields->get('_dateOutputFormat');
	foreach($f->getOptions() as $value => $label) {
		$f->replaceOption($value, $value, $label . ' [' . $value . ']');
	}
});

So I'm in favor of the original suggestion of a date with a month > 12 and a (shortened) year > 31 to remove all ambiguity.

[BernhardBaumrock]

thx @BitPoet

This is the result and I think it would be a good solution.

But yes, a regular date is better to read:

wire()->addHookAfter('InputfieldDatetime::getConfigInputfields', function(HooKEvent $event) {
  $inputfields = $event->return;
  
  $f = $inputfields->get('_dateInputFormat');
  foreach($f->getOptions() as $value => $label) {
    $f->replaceOption($value, $value, date($value, strtotime("1970-12-31")));
  }
});

wire()->addHookAfter('FieldtypeDatetime::getConfigInputfields', function(HooKEvent $event) {
  $inputfields = $event->return;
  
  $f = $inputfields->get('_dateOutputFormat');
  foreach($f->getOptions() as $value => $label) {
    $f->replaceOption($value, $value, date($value, strtotime("1970-12-31")));
  }
});

[ryancramerdesign]

I'm not partial to any particular date, but one of the primary differences between the date formats involves leading zeros before the month and/or day. And so you need a date with single digit month and day to be able to tell the difference. Otherwise you end up with several of the exact same date example without a way to tell them apart. Whereas, you can tell what is month and day just due to the fact that the same date is used on all of the examples.

I have updated it so that it uses today's date for the example, unless today's date results in colliding results because it fails to show the the difference in leading zeros. When that happens, it falls back to the previous example date which is clear about leading vs. non-leading zeros in months and days. I've also updated it so that it appends the date format like in BitPoet's screenshot. Though PHP date formats are a little cryptic, but it still seems worthwhile.

[BernhardBaumrock]

Thx! :)