cache.inc notice

Why not couple that into a !empty($user->cache)?

If you just need to see if it is set, why do you have "&& $user->cache" after that?

Where does core use or our coding guidelines suggest this pattern to "improve performance"?

Ok, misread the patch, sorry. Committed!

I don't think would be an issue any more, I couldn't find the code patched in #13 at all. I guess it's been refactored significantly since. The closest I could find was:

  /**
   * Prepares a cached item.
   *
   * Checks that items are either permanent or did not expire, and unserializes
   * data as appropriate.
   *
   * @param $cache
   *   An item loaded from cache_get() or cache_get_multiple().
   *
   * @return
   *   The item with data unserialized as appropriate or FALSE if there is no
   *   valid item to load.
   */
  protected function prepareItem($cache) {
    global $user;

    if (!isset($cache->data)) {
      return FALSE;
    }
    // If the cached data is temporary and subject to a per-user minimum
    // lifetime, compare the cache entry timestamp with the user session
    // cache_expiration timestamp. If the cache entry is too old, ignore it.
    if ($cache->expire != CACHE_PERMANENT && variable_get('cache_lifetime', 0) && isset($_SESSION['cache_expiration'][$this->bin]) && $_SESSION['cache_expiration'][$this->bin] > $cache->created) {
      // Ignore cache data that is too old and thus not valid for this user.
      return FALSE;
    }

    // If the data is permanent or not subject to a minimum cache lifetime,
    // unserialize and return the cached data.
    if ($cache->serialized) {
      $cache->data = unserialize($cache->data);
    }

    return $cache;
  }

Which looks like it already has an isset() check, albeit for a different variable.

If this is a bug report for D7, we should write a test to show that it exists, but I think maybe we should just confirm manually that it does before going that far.

#2094585: [policy, no patch] Core review bonus for #2025699: Consolidate 'datetime'/'datetime_form' and 'datelist'/'datelist_form' #type and #theme names for consistency.

Tagging for an issue summary update so we can get clear steps to reproduce the issue.