When I get email notification/copy of submitted webform I get "July 29 2008" no matter whether people write 29, 30 or 31! In the DB on my site the date is correct.

So - because of this I have bugged people about the date until someone showed that they are correct on the site (in the saved data).

Comments

humble’s picture

Version: 6.x-2.0-beta6 » 5.x-2.0

This also seems to affect 5.x.2.0. The date in the e-mail differs from that in the DB by one day.

xqi’s picture

Component: Miscellaneous » Code

bump, i got the same problem. i think it has something to do with GMT/time zone settings.

i have tried to set the date field as "Website Timezone" or "GMT" and both of them give 1 day lag in email.

my site has disabled configurable timezone for users. i doubt we need timezone manipulation when creating email. whatever user has submitted is what we want in the email.


function theme_webform_mail_date($data, $component) {
  $output = $component['name'] .":";
  if ($data['month'] && $data['day']) {
    $timestamp = strtotime($data['month'] ."/". $data['day'] ."/". $data['year']);
    /* allow for PHP timezone offset */
    $tz_offset = strtotime(date("M d Y H:i:s")) - strtotime(gmdate("M d Y H:i:s"));
    $timestamp += $tz_offset;                                                        //  i think this is where the problem came from
    $output .= " ". format_date($timestamp, "custom", 'F j, Y', NULL);     
  }
  return $output;
}


quicksketch’s picture

This was an on-going issue for months. The e-mail was being sent out a day earlier that submitted. I was really hoping the problem had been fixed, but doesn't seem this is the case :(

http://drupal.org/node/187449

I'm thinking we just omit the use of format_date() entirely, as it's the one doing funny timezone conversions. Like you state, we really just want the date the user entered.

function theme_webform_mail_date($data, $component) {
  $output = $component['name'] .":";
  if ($data['month'] && $data['day']) {
    $timestamp = strtotime($data['month'] ."/". $data['day'] ."/". $data['year']);
    $output .= " ". date('F j, Y', $timestamp);   
  }
  return $output;
}
quicksketch’s picture

Status: Active » Fixed

I've used the above method in the newest version of date.inc. Please try out the latest dev or CVS version and open a new issue for any new problems. Thanks!

Drupal 5: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/webform/compo...
Drupal 6: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/webform/compo...

jmwhitco’s picture

Hi there...I'm not 100% certain how this works, so can someone tell me when/how this fix should be put into the download version of the module. I downloaded 5.x-2.0 yesterday, and the date.inc file shows as 'date.inc,v 1.13.2.15.2.3 2008/04/15 09:20:37' which would be the unpatched version. How/when does this get updated to '1.13.2.15.2.4, Sat Jun 7 18:20:38'?

The post is marked fixed...does it need to be tested by others before it is put into the downloadable version of the module?

Thanks.

quicksketch’s picture

mwhitco, Thanks for your interest in testing the fix. The release on the project page (2.0) will remain the same until the new 2.1 version comes out, which is generally at the discretion of the module maintainer (that's me). There are a couple ways you can test this.

1) Follow the above links, then click the "Patch" link to get a diff of the code changes. You can then apply that diff to your copy of Webform by applying the patch. Information on how to do that is here: http://drupal.org/patch/apply. This is generally the way all work is done in Drupal, so becoming familiar with patch and diff can help out a lot with testing patches in the future.

2) Alternatively, you can just download the development version of the module, which contains all the latest fixes (but might also contain new problems). Go to the Webform project page, then click "View all releases". Find the version "webform 5.x-2.x-dev", which is where this fix has already been applied (hence why the issue is marked fixed).

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.