Add setting to use site-wide date formatting strings instead of our own weird setting

yup, i just looked, and the way signup is handling date formatting is pretty stupid. ;) there's a signup-specific date formatting variable it's testing, but this variable is never show on the signup settings page. search for "signup_date_string" in the code, and you'll see what i mean. there are actually 4 places that need fixing.

that said, this is a minor bug, and i have no need to fix it anytime soon. so, here's a good chance for someone else to contribute a patch to this module. ;)

Any solution?

... here's a good chance for someone else to contribute a patch to this module. ;)

:p ... I've made a small patch that makes the signup module use the format_date API function.

I've attached two version. One where a custom format ('M j Y, G:i' and not 'M jS, g:i A' to get rid of the untranslated ordinal suffix for the day of the month (st, nd, rd or th)) is used and optionally the signup_date_string variable; and another that uses the global 'small' format.

hmmm I'm not sure whether the offset has to be passed too.

http://api.drupal.org/api/function/format_date :

format_date($timestamp, $type = 'medium', $format = '', $timezone = NULL, $langcode = NULL)
$timezone Time zone offset in seconds; if omitted, the user's time zone is used.

The format date in the reminder mail is still unchanged.
I'm using the globalSmallFormat patch and it works correctly only in the signup tab for admins.

re #5: i'd prefer to just use the site-wide settings for this, instead of our own custom format. that said, a knob to select if you want "small", "medium", or "long", etc might be handy. or, just hard-code the 'small' version for now...

re #7: then the patch still needs work. ;)

Committed to HEAD. Honestly, I'm calling this a feature, not a bug fix. It wasn't actually a bug, it's just that signup used to use a weird, undocumented setting of its own to control these dates. Now, there's just a new setting to use one of the existing core dates...

Wow, good thing I tested this some more before I created the 5.x-2.5 release. event 5.x-1.* doesn't work like I thought, and _event_date() doesn't know about the core format string settings. :( See http://drupal.org/cvs?commit=147140