Remove custom Webform "timezone" handling

Could you list the following:

- Where is your server located (east coast, central, west coast, etc)
- What time zone do you have set at admin/settings/date-time
- Do you have Date API installed?
- What are the exact settings for your component

What is your 'First Day of Week' set to under Administer -> Site Configuration -> Date and Time ?

I was having a problem with the calendar module the other day so I change the start of the week to Monday and it worked out.

Okay, this is a strange problem. Technically Webform is "correct" but this is not expected behavior. Basically here's how the logic works:

- Webform calculates "today" as being a timestamp for midnight at GMT.
- Then using timezone correction of -0500 (EST), "today" at GMT is actually yesterday.

You can get the expected behavior by using "now" instead of "today", because "now" will calculate based off of the current time, not midnight at GMT.

I think it might make sense to fix this simply my replacing "today" with "now", but that won't fix things like "yesterday" (which would end up being day before yesterday).

I'm moving this to a task to generally fix Webform's handling of dates, times, and timezones. In Drupal 6 we have true timezone handling provided by Date module, and in Drupal 7, it's now completely native. There's no need to bother the user with an option to use "Daylight savings", since we now know which timezones have Daylight Savings and which ones don't, so based on the site or user configuration we can figure this out automatically. This set of changes should include the following:

- Remove the "Daylight savings" setting entirely, using existing timezone mechanisms in Drupal 7 and DateAPI for Drupal 6.
- Remove the "GMT" option, since that doesn't make sense in 90% of situations. In those situations, a user could set their timezone to GMT or the site setting could be set to GMT. It's important to note no matter what, dates have always been stored in GMT no matter what this option is set to, it just determines the default value.
- In the process of these changes, the original problem discovered in this issue will be addressed ("today" showing up as "yesterday").
- Now that we have #709854: Convert date component database storage to use ISO 8601 strings (similar to timestamps), we should also avoid timestamps wherever possible, since we've standardized on a much better format of ISO 8601 strings.

Well, the final solutions that I found were slightly disheartening. In order to do timezones correctly in Drupal 6, you need both PHP 5.2 and DateAPI. However to do the same thing in Drupal 7, we don't need anything (since Drupal requires PHP 5.2 anyway and Date API is built-in). So my final solution has been to provide really great timezone handling if you've got these requirements, and no support for timezones if you don't have these requirements, since we've been calculating them wrong anyway and after hours and hours I couldn't find a way to do them correctly. No support is better than the wrong support, which is about all we're going to get unless you have these requirements.

So this patch now does the following:
- Removes "GMT" as an option entirely, because it is not useful in 90%+ of situations.
- Removes "Daylight savings" option entirely, since this is dependent on timezone.
- Hides the "Timezone" settings if user configurable timezones is not enabled.
- Hides the "Timezone" settings if suitable timezone handling is not available (DateAPI and PHP 5.2, or Drupal 7)
- Fallbacks to simple, default time handling in the event that true timezones are not available, essentially using the server time.

This actually does fix the "today" == "yesterday" problem, but it makes it so that the default values for times are going to match the server time, which may not be the same as the Drupal site time settings.

I pulled from CVS this morning, and am getting errors with time fields in Drupal 6.15 with php 5.2.6 and Date Development version 6.x-2.x-dev (2010-Mar-10):

* warning: Illegal offset type in isset or empty in /net/www/fsd-intranet/includes/form.inc on line 804.
* warning: Illegal offset type in /net/www/fsd-intranet/includes/form.inc on line 805.
* Start Time field is required.
* warning: Illegal offset type in isset or empty in /net/www/fsd-intranet/includes/form.inc on line 804.
* warning: Illegal offset type in /net/www/fsd-intranet/includes/form.inc on line 805.
* End Time field is required.

edit:This only occurs with 12 hour time selection, changing it to 24 hour stops the error.

Did you run update.php? The latest dev makes MAJOR database changes, be sure to make a backup.

I just checked and yes I have run update.php.

I just realized:

* Start Time field is required.
* End Time field is required.

These errors, when are you getting them? Webform itself doesn't contain start and end times anywhere. Do you have two time fields set up, and then didn't fill them out? I need steps to reproduce this error.

Here we go, I think this should fix the problem. Please open a new issue for further problems so we can solve it separately there.

It has reduced the amount of error message output, but still getting some. see:
http://drupal.org/node/752414