function format_date in common.inc is using gmdate() incorrectly. the function is trying to format a local timestamp, and GMT conversion is incorrect in this case. date() should be used instead. bug also exists in 4.6, and this patch should apply there, too. haven't checked the earlier versions of drupal...

CommentFileSizeAuthor
format_date.patch817 byteshunmonk
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented
Status: Active » Needs review

switching to patch status

ezheidtmann’s picture

ezheidtmann CreditAttribution: ezheidtmann commented

Are you sure about the logic here? I've tried to fix timezone issues before, and I always get confused. My reading of the documentation makes me think your patch is wrong:

If the timestamp has already been converted to a localized time, then gmdate() should be used because gmdate() does no timezone adjustments (it does not care what PHP's timezone settings are). Using date() is incorrect because it does care what PHP's timezone settings are.

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented

i'm fairly certain that my logic is correct here. the php doc on gmdate() is not totally clear, but i think that if you read it over closely, you'll see that it's the other way around--gmdate() is actually the one that adjusts the timestamp passed. i would recommend writing some short scripts to test out how gmdate() and date() actually operate(that's what i had to do!)--i think you'll see that what happens is gmdate() takes the timestamp passed, applies the server timezone offset, and returns the (formatted) result as GMT. that's what my tests have shown, and for the format_date function, this operation is incorrect--the goal of the function is to simply make the timestamp passed into a human-readable date. no adjustment is necessary.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
Status: Needs review » Reviewed & tested by the community

I think it is obvious that the display function is overcorrecting.

At the top of the function we correct for Drupal server time or user tz and then wwe later again shift the zone.

print date('D, M jS, G:i', time()-date('Z'));

print gmdate('D, M jS, G:i', time());

this code gives the same for me and shows that the timestmap is further modified.

hunmonk’s picture

hunmonk CreditAttribution: hunmonk commented
Status: Reviewed & tested by the community » Closed (fixed)

closing this for now, as i've further investigated php's time handling functions, and i don't believe this is the best solution. my plan is to do a comprehensive search of core to properly correct any timezone/timestamp issues, and post one patch for the whole thing if necessary