format_date() does not support "c", "e", "P", "T" specifiers, displays GMT for all

Good catch, but bugs get fixed in the current development version first (D7) before being backported.

This is already fixed in Drupal 7. However, in Drupal 6, the "e" format specifier (time zone identifier, examples: UTC, Atlantic/Azores) cannot be properly supported because Drupal 6 has no idea what named time zone you are formatting the date for. It only has a (faulty) concept of time zone offsets from GMT. So it seems best to not add "e".

Would it be acceptable to at least add support for c and P, and document the lack of 'e' support in the function's doxygen comment? If so I'd be happy to roll the patch.

@adamdicarlo: sounds good.

subscribing - hope this makes it in soon.

Here's a new patch -- hopefully my addition to the function header comment is clear enough.

Similar, #646932: format_date incorrectly formats all timezone identifiers as 'GMT', but fixes issue described here.

I'm sure I am mistaken here, BUT, my brief amount of testing has shown that if I correctly set the site's timezone the value for e is correct when I've patched with #646932: format_date incorrectly formats all timezone identifiers as 'GMT'. I THINK mfb in #2 is only for gmdate() since it will only ever return GMT.

The time zone value for date('e') would depend on the server environment's time zone setting. It's certainly possible to get a correct value, but could also be incorrect depending on the server environment.

The patch at #6 definitely doesn't work because it will always output a GMT time zone while the date/time will have an offset applied, which results in incorrect output for e.g. format_date(time(), 'custom', 'c')

The more I get into this issue I realize D6 wasn't designed to support these specifiers. These guys come from the server environment, as per #9. Check out the screen shots. The only thing I'm doing is changing the timezone on my computer. Notice that the actual time DOESN'T change.

Now that doesn't mean you can't use c,e,P,T.

What I've found best is

1. Disabling user specific timezones in admin/settings/date-time
2. Making sure the servers timezone is set to what you want Drupal's to be

• You can drop date_default_timezone_set('America/Los_Angeles'); into settings.php
• Configure php.ini's date.timezone
• Modify httpd.conf, vhost or .htaccess with SetEnv TZ location

I've also included a documentation fix as per adamdicarlo in #6. 494434-11-fix.patch, in #11 below, needs to be reviewed.

Don't use the two patches included here use the ones in #11.

Ignore the two patches in #10, I wasn't in the root directory when I made them. These are what you want.

Note that the year, month, day, hour, and minutes are also affected by the timezone. So Y, m, d, H, i and some others too are all wrong too. It seems to me that gmdate() should never be used in a function that is expected to be used with a local date.

Thank you.
Alexis Wilke