Date on e-mail sent is 1 day earlier.

I have the same problem, has anyone pinpointed or created a patch for it?

Database and 'results' tab of the webform show the correct date, only the email sent is off by one day.
This is very disturbing as we use it for input on date of birth.

I've been searching through the code but it all seems fine ... where does this come from? Anyone from the dev-team of this module know why?

Same here, also for a restaurant booking.
Is there a patch available yet??

Any updates yet? Please let us know :)

Is the problem that the function theme_webform_mail_date in components > date.inc has a format_date call that needs to be rewritten from this...

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

to this ...

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

I believe from the API that format_date is expecting the last parameter to be a timestamp offset in seconds. If omitted, the user's time zone is used. In this case 0 would be interpreted differently from NULL. Seemed to work for me.

Didn't work for me ...

Same here, didn't work for me either....
I really need this to work correctly. Any updates so far?

Hmm, very unclear why this should be happening. The date is stored in the database as the three separate components (day, month, year) which you can see being dropped in on line 4 of the theme_webform_mail_date function...

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

It's converted to a UNIX timestamp and then run through format_date to make it a nice readable string for the email. Couldn't be more simple.

I think the problem is something to do with the timezone in the format_date call. strtotime($data['month'] ."/". $data['day'] ."/". $data['year']) creates the timestamp at midnight (00:00 on month/day/year). If 0 is used for a timezone setting, then the timestamp will (I think) be GMT. If your timezone is forward of GMT, then the format_date call would work with a time behind your timezone, giving you the date for the previous day. Does that make sense...?

Hard to see what's going wrong without it being something related to the timezone setting, here and in the site settings. 0 is an integer/numeric and not the same as NULL.

Do you have a 'default value' set for your date component(s)? Does that make a difference?

The webform date component has a timezone option - that doesn't seem to be picked up in the theme_webform_mail_date function at the moment, so can't be anything to do with that.

Do you have user-configurable timezones in your Drupal installation? Is your site timezone set correctly?

I still think it should be

    $output .= " ". format_date($timestamp, "custom", 'F j, Y', NULL);

Has anybody noticed that in the month/day selection pop ups to first entry is "month" and "day", respectively? When selected, it results in an invalid date error, but still not looking good to the untrainned eye.

Changing the output line as suggested in post 9 did the job here...

In the end it proved to be both for me ...

My site was set in GMT (instead of CET) _and_ the line had to be adjusted from 0 to NULL

tnx

Changing 0 to NULL made no difference for me, it's still a day off.

I suspect the output from strtotime() is affected by the timezone as PHP knows it, set on the server.
The format_date() function then applies Drupal-specific timezone on a timestamp that may not be GMT.

PHP here is set GMT+1000 with Drupal set the same. I think this caused date in email to be 20 hours behind.
Attached patch which works here. I'd be interested to know if this works for others in various timezones.

It's not great code, though best solution I could find without requiring PHP 5.1+

Brendan's patch fixes my issue, which is no surprise considering we're working on the same project.

Can we get some more testers on the latest patch?

This code patch is also working ok for me.
Thank you

Works for me too.

Thanks guys.

Didn't have any affect for me I'm afraid. Still the same problem of being 1 day behind.

Got the same error in Webform 2 beta 3, with "NULL" instead of "0" it worked for me...

regards pebosi

Thanks everyone. I'm assuming that this fixes most sites, or at the very worst, doesn't cause harm to existing sites. Committed.

Anyone feeling ambitious can clean it up, but this has been going on so long I'd prefer just to leave it be and not touch it :)

I'm having this issue on 5.x-2.9 submissions. I've played around with the code and realized if I left all settings default and just went straight with format_date($timestamp); I still had the error.

This may mean that there is nothing wrong with the module, and that it is an issue with my drupal install. If that is the case then I apologize for re-opening this but this seemed to be the most relevant place to post

Any help is appreciated.

If you're getting the wrong date, you probably just need to adjust your time-zone settings at admin/settings/date-time. Often times this needs to be set to the same timezone as where the server is located, not where the site's target audience is.

I have this issue with version 6.x-2.9. I have confirmed that changing the site time to match the server time fixes the issue. However, not everyone can sync those values. Is some other solution possible if you can't change your server time and your site requires a different time zone?

my server and site are both configured to be Eastern Time. User Timezone has been disabled. Date Component in WebForm is set to be Site Timezone. However I still have this issue.

in drupal's format_date() method

function format_date($timestamp, $type = 'medium', $format = '', $timezone = NULL, $langcode = NULL) {
  if (!isset($timezone)) {
    global $user;
    if (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
      $timezone = $user->timezone;
    }
    else {
      $timezone = variable_get('date_default_timezone', 0); 
    }
  }

  $timestamp += $timezone; //where the difference is from

it looks like Drupal always treats the Date Component's datestamp as UTC timezone (in the theme_mail function) and tries to convert it to the site time zone. which is how the difference was created.

change

$output .= ' '. format_date($timestamp, 'custom', $format);

to

$output .= ' '. format_date($timestamp, 'custom', $format, 0);

this should fix the issue.

never mind, just found this

http://drupal.org/node/375874

so the dev version should be good

All patches #29 and all that is described at the link at #30 doesn't work for me, webform 6.x-2.9.
I'm using werbform for bookings and the problem is, that the date in the confirmation mail is always -1 day, if the date ist greater then Day 28 of the month where the webform is submitted.

To reproduce the error:
If today is march, 09, 2010

Send a webform with following dates
march 12 2010 -> works fine
march 13 2010 -> works fine
march 14 2010 -> works fine
....
march 27 2010 -> works fine
march 28 2010 -> day -1 error: in the confirmation mail the day is march 27 2010
march 29 2010 -> day -1 error: in the confirmation mail the day is march 28 2010
...
july 1 2010 -> day -1 error: in the confirmation mail the day is June 30 2010

The error occurs regardless which time zone settings are made on Websites date/time settings or webform component Time Zone Settings.

Patch at #15 works for me and the dates in the confirmation mails are shown correct.

The bug needs to review to fix next versions of webform.

This has got to be fixed. I just used the fix in #29, and it appears to have done the trick, but this has caused a major problem for my client. Users were supposed to register their arrival dates for a trip, as well as their birthdates (required for booking air), and the emails that went to the traveler and my client showed them arriving one day earlier than they actually were and with the wrong birth date. (The information stored on the site appears to have been correct, but my client worked off of the emails she received). Hotel rooms were booked based on that information, and it's going to be a mess to unravel the problem. To be fair, we should have submitted test data to make sure everything was working correctly before we let travelers start using this, but still. I look like a dip, my client looks like a dip, it's bad all around. This is an obscure, but potentially very harmful bug. A new stable version of webform should be put out that absolutely 100% fixes this bug, so that others don't get stung by this bug.

My client does love the way the webform works other than this huge inconvenience she now has to deal with.

This has already been fixed in #375874: Use Drupal's date_format function to theme dates in mails, as xqi said in #30, we just haven't put out a new version yet.

@DrupalYedi your error is probably caused by the daylightsaving time (DST) that starts in March. This causes format_date one day earlier (0 am will become 11pm previous day). Issue in format_date is solved in Drupal 7, see issue #605730: format_date wrongly adjusts dates for timezones for a workaround.