/admin/config/regional/date-time does not show the correct default format for short and medium format

Thanks for the bug report!
It will need to be fixed in D8 first.

dblog uses in d7

array('data' => t('Date'), 'header' => TRUE),
format_date($dblog->timestamp, 'long'),

Not the short date, so if you change the long date does what is displayed change?

The long date format is used on the watchdog event details page. The short format is used on the Recent log messages page (the overview).

From dblog_overview():

        // Cells
        array('class' => 'icon'),
        t($dblog->type),
        format_date($dblog->timestamp, 'short'),
        ...

The issue occurs for both medium and short timestamps, and is caused by a mismatch between the way format_date() works out the format to use and the date format options listed on the Date and time settings page (from system.module).

format_date() uses a variable_get() to load the format, with a default value specified. The settings page loads all available formats using hook_date_formats() and picks the first one if none are set. Both short and medium formats have a different first date (provided by system_date_formats() than the default value given to variable_get().

See attached screenshots of the dblog report and system settings page showing the different defaults (this is a vanilla D7 install using latest 7.x head).

This patch ensures the default formats match by re-ordering the dates listed in system_date_formats(). Not that this will not change the formats in use on the site.

We could change the default values given to variable_get() instead, but this would change/break existing sites which use the default formats.

This issue doesn't affect D8 due to the new date/time system.

I guess even for 7.x we have to adds tests.

OK, test added.

I've amended the patch to be more explicit when checking the date config page.

The patch code #9 looks good to me. As for the test, the test failed because the test case enabled Locale module. Locale module hides this bug, I believe.

1.

DateTimeFunctionalTest enables Locale module:

  function setUp() {
    parent::setUp(array('locale'));

    // Create admin user and log in admin user.
    $this->admin_user = $this->drupalCreateUser(array('administer site configuration'));
    $this->drupalLogin($this->admin_user);
  }

We should create a new test class with Locale module disabled to verify this patch, I think.

2.

+      // Check that the configuration fields match the default format.
+      $this->assertFieldByXPath(
+        "//select[@name=date_format_{$format_name}]/option[@selected='selected']",
+        $format_value,
+        t('The @type format type matches the expected format @format',
+        array(
+          '@type' => $format_name,
+          '@format' => $format_value,
+        )
+      ));

We may use DrupalWebTestCase::assertOptionSelected() here.

https://api.drupal.org/api/drupal/modules%21simpletest%21drupal_web_test...

Thanks @hgoto. I spent so long looking for an alternative to xpath!

Now we are targeting the date and time setting page rather than the dblog page. Let's update the issue title and summary.

Thank you, markpavlitski. I tested the patch #13 manually and confirmed it fixed the issue.

I think it's OK to move this to RTBC but I'd like someone else to review this to be sure :)

Works nicely. My only thought is the default date should be a universal one, ie Y-m-d, rather than a regional one, m/d/Y. But the patch that's here applies cleanly and works, so marking as RTBC.

@Sophie.SK - thanks!

The reason for leaving the North American default format as-is is to ensure that existing sites aren't impacted by the change. Possibly a follow-up issue could try to address that?

@markpavlitski That makes sense. A follow-up issue might be useful, but I guess it's going to be a super-low priority one if it's only D7 affected.

Marking for commit, nice work @all! :)

Thanks @Fabianx! This issue has been bugging me for ages!

Looks good to me as well, assigning to David for final review

Committed to 7.x - thanks!

It would be nice to have a followup issue to port these tests to Drupal 8, I think.

I was wondering if there are any side effects from having a date format that is limited to the en-us locale as the first one on the list, but I couldn't find any problems. (It seems that locale info isn't really even used at all?)

I fixed the following on commit (since assertion messages shouldn't be translated):

diff --git a/modules/system/system.test b/modules/system/system.test
index 5571b7d..9eaf562 100644
--- a/modules/system/system.test
+++ b/modules/system/system.test
@@ -1505,7 +1505,7 @@ class DateFormatTestCase extends DrupalWebTestCase {
       $this->assertOptionSelected(
         $id,
         $format_value,
-        t('The @type format type matches the expected format @format',
+        format_string('The @type format type matches the expected format @format.',
         array(
           '@type' => $format_name,
           '@format' => $format_value,