_system_date_format_types_build improper use of in_array

And a patch.

The visible problem caused by this bug is that _system_date_format_types_build() doesn't return the proper 'module' array keys. What happens is we first query all modules for their custom date formats. Then we ask the database what it knows about -- formats which originate from modules should be preserved, but instead the current code treats everything as originating from the database.

A simple dpm($types); before and after the

  // Get custom formats added to the database by the end user.
  $result = db_query('SELECT dft.type, dft.title, dft.locked FROM {date_format_type} dft ORDER BY dft.title');
  foreach ($result as $record) {

block of code will confirm this.

Summary of the issue:
_system_date_format_types_build() builds and returns information about available date types. It first queries modules to determine what date formats they provide, storing the information in $types. It then queries the database about all known date formats, which includes date formats from modules and custom date formats entered manually. The method to determine whether a database $record is a custom date format (i.e., not from a module) is flawed. The current check is
!in_array($record->type, $types)
which will always return true since, for example, $record->type is long, but $types is:

Array
(
...
    [long] => Array
        (
            [module] => system
            [type] => long
            [title] => Long
            [locked] => 1
            [is_new] => 1
        )
...

The proper test would instead be !isset($types[$record->type]).

Solution:
The proposed patch in #1.