Test for format_date

+  /**
+   * Helper function: asserts that format_date() creates the same formated
+   * string as gmdate() does.
+   */

This is not an unit test: a proper unit test assert that the result of a function call is identical to the known expected behavior. Comparing the result of format_date() (that uses gmdate() internally) to the result of gmdate() has no real purpose.

What you should do here is prepare an test case of some specific date values and their known text representations, and use that to verify that format_date() works correctly. Including some known corner-case values is of course better (leap years, days with leap seconds, negative timestamp values, etc.).

I do not believe so that would be going through and testing out what gmdate() does internally to drupal, this is to check the 'Format of the date' based on drupal parameters such as localized time.

This makes even less sense. In a nutshell you are currently doing (simplified version of your assertFormatDate):

  // Get the current system time and add the time zone.
  $localized_time = $time + $time_zone;
  $date = gmdate($format, $time);
  $drupal_date = format_date($time, $format);

So (1) you are assuming that the current language is english, and (2) you are basically testing only one line of format_date(), the one that does:

  $timestamp += $timezone;

Here's a fresh start on format_date() unit tests.

drupal.org ate my patch :(

Removed some debug code from the assertions.

Committed to CVS HEAD. Thanks.

Some of these assertions fail if the test environment has spanish language installed. I modified it to create a custom language "xx".

Add a test for backslash followed by escaped format string.

@mfb: Thank you for pointing me in the right direction. That patch looks great and should be reasonably effective in identifying issues with the format_date function.

I think that it might be worthwhile to add an "every special format character" test condition, i.e:

$format = 'F A a e D l M T';

That was the condition that resulted in my adding 0-9, + and : to the regex.

It occurred to me that numbers would be an issue when I visited the "List of Supported Timezones" "Others" page.

@jrchamp: There shouldn't be any numbers colons or plus signs because Drupal doesn't allow the "Other" time zones to be configured. As it says, "Please do not use any of the timezones listed here (besides UTC), they only exist for backward compatible reasons." The only way they would show up was someone manually hacking their database :)

@mfb: Nice catch! It turns out that if you don't call date_timezone_set(), it returns "July PM pm +00:00 Wed Wednesday Jul GMT+0000" instead of "July PM pm UTC Wed Wednesday Jul UTC". Thankfully this shouldn't happen.

I committed the patch at #11 because it is an improvement. I'm _not_ marking this fix because we have follow-up patches to make.