warning: gmdate() [function.gmdate]: Windows does not support dates prior to midnight (00:00:00), January 1, 1970 ...

http://drupal.org/node/20869 has the same error message (make sure when you're searching for bugs that you check the closed and duplicates too). the bug was supposedly "fixed" it but as you noticed, it doesn't work.
http://drupal.org/node/31193 i wrote a patch for this a couple of weeks ago but it hasn't been committed yet, you could probably tweak it to apply to the 4_6 branch.

yeah that last patch was for the HEAD version, I've attached a patch that backports the fix for this bug to 4.6. I'll warn you, I didn't fire up 4.6 to test this so it may not work. If you could post some feedback either way, that would be helpful.

Here's the complete function:

/**
 * Validates the start and end times in a node form submission.
 * - Changes 24 hour time to 12 hour time (if the module is configured to do this).
 *  - Adjusts times for time zone offsets.
 *
 * @ingroup event_support
 * @param $node The submitted node with form data.
 * @param $date The name of the event's date ('start' or 'end') to validate and set.
 */
function event_validate_form_date(&$node, $date) {
  $prefix = $date .'_';

  // If we have all the parameters, re-calculate $node->event_$date .
  if (isset($node->{$prefix . 'year'}) && isset($node->{$prefix . 'month'}) && isset($node->{$prefix . 'day'}) && isset($node->{$prefix . 'hour'}) && isset($node->{$prefix . 'minute'})) {
    $hour = $node->{$prefix . 'hour'};
    if (variable_get('event_ampm', '0')) {
      if (($node->{$prefix . 'ampm'} == 'pm') && ($hour != 12)) {
        $hour += 12;
      }
      elseif (($node->{$prefix . 'ampm'} == 'am') && ($hour == 12)) {
        $hour -= 12;
      }
    }
    // translate the input values to GMT and set the node property value
    $offset = event_get_offset($node->timezone, gmmktime($hour, $node->{$prefix . 'minute'}, 0, $node->{$prefix . 'month'}, $node->{$prefix . 'day'}, $node->{$prefix . 'year'}));
    $node->{'event_'. $date} = _event_mktime($hour, $node->{$prefix . 'minute'}, 0, $node->{$prefix . 'month'}, $node->{$prefix . 'day'}, $node->{$prefix . 'year'}, $offset);
  }
  elseif (!$node->$date) {
    // Round to nearest hour:
    $now = _event_user_time();
    $node->$date = $now - ($now % (60 * 60));
  }
}

It might be easier to do this debugging over IM. Drop me a message with a AIM, MSN, or Google Talk username or if you're interested.

Have you tried creating a new event and running the process? I'm curious if these warnings are coming from nodes that are already in the database and haven't been updated after the change.

Okay, that last patch was actually headed in the wrong direction.

The problem seems to be that when the node's even info is saved it's done with an UPDATE rather than a DELETE and INSERT. Normally this is more effecent but it doesn't work if there's no record in the event table, the changes will never be saved. This will happen if you create nodes, then enable tracking of event details for that node type. The event record wasn't created during the initial INSERT so the UPDATEs won't ever work.

This is a problem in both 4.6 and HEAD. I've attached a patch for 4.6, bigbman, would you mind giving it a try? Or, since you said your patch wasn't working, change lines starting at 1704 to:

    case 'insert':
      if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never') {
        db_query('INSERT INTO {event} (nid, event_start, event_end, timezone) VALUES (%d, %d, %d, %d)', $node->nid, $node->event_start, $node->event_end, $node->timezone);
      }
      event_set_range();
      break;

    case 'update':
      if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never') {
        // while this looks a little kludgy, if you simply do an update you won't
        // create records for nodes created before the event module was enabled.
        db_query('DELETE FROM {event} WHERE nid = %d', $node->nid);
        db_query('INSERT INTO {event} (nid, event_start, event_end, timezone) VALUES (%d, %d, %d, %d)', $node->nid, $node->event_start, $node->event_end, $node->timezone);
      }
      event_set_range();
      break;

here's the patch for HEAD. i expanded the comment a bit to make it clearer.

I should also mention that while I tested the 4.6 patch, I didn't try out the one for HEAD.

bigbman, i wasn't very clear, you'll need to get a clean copy of event.module and then paste in the changed lines.

if you want you can grab the latest copy from CVS.

drewish, I have the same exact problem that bigbman has.

By "get a clean copy of event.module", did you mean get the CVS copy? I am using Drupal 4.6, not the CVS version. Is the CVS version of the event module compatible with Drupal 4.6 ?

Thank you,

diego_jarrin, I recommended that bigbman get a clean copy because I'd had him make changes to his file. CVS contains copies for both 4.6 and the, unrelease, 4.7. The CVS link I posted was to the 4.6 branch.

If you haven't made any customizations you should be able to just make the changes listed in comment #9. If you have made changes you can just download a new copy of the event module and overwrite your old one or as I mentioned, grab a copy from CVS.

Hopefully that makes sense.

I have a clean event module, and I made the changes to the module as suggested in comment #9 above. However, the problem persists.

The problem occurs when I try to add any node type if I have allowed that node type to show in the event calendar (in admin/node/configure/types/blog). Here is the warning again:

warning: gmdate() [function.gmdate]: Windows does not support dates prior to midnight (00:00:00), January 1, 1970 in E:\Websites\cms\drupal\includes\common.inc on line 888.

On the bright side, the events do get added to the events calendar, so it doesn't prevent the calendar from working. I'm thinking that if there is a way to prevent the warning itself from appear, we wouldn't necessarily have to fix the problem.

Any ideas?

Thanks for your help !!

Diego

It seems this problem has been around for a VERY long time.

See http://drupal.org/node/1418

If you do a search in Google for "warning: gmdate() [function.gmdate]: Windows does not support dates prior to midnight (00:00:00)" you'll see that there are tons of Drupal websites that present very similar problems.

This seems like a pretty serious issue that probably affects not only the Event module but probably other modules as well. After all this time with this same problem I would imagine that someone would have come up with a solution or a replacement for gmdate?

Anybody?

this is not fundamentally a drupal bug--it is poor windows handling of timestamps. from the php manual:

Note:
In the Microsoft Windows series of Operating Systems the system libraries implementing this function are broken, so gmdate() does not support negative values for the timestamp. For details see bug reports: » #22620, » #22457, and » #14391.

This problem does not occur in Unix/Linux Operating Systems, as the system libraries behave as expected.

PHP cannot fix broken system libraries. Contact your OS vendor for a fix to this and similar problems.

one way around this is to put in a check for a negative timestamp value anywhere format_date is called, and simply bypass the function. another good option would be to change your operating system ;)

diego_jarrin, the warning is pretty generic, there's plenty of reasons you could get it. I think you'll keep seeing them until you update all the nodes with missing dates.

hunmonk, the problem isn't with Windows. The problem is that no timestamp is being loaded. When you add the timezone offset (which will be negative for timezones east of GMT) to zero, you'll get a negative time. It doesn't work any better on UNIX (1969 isn't much better than 1970 in this case) but you won't get the warning.

Okay, so after working with bigbman via IM, I present the following patch. It works for him so I hope it works for all the other 4.6 users.

The previous patch for HEAD (on comment #9) is still correct.

Just a note that I won't accept any OS specific patches.

Ah, ok, the patch isn't OS specific. I don't understand the comment, though. in fact it doesn't make any sense to me.

Killes, Glad you looked at the prior comments and code before posting ;)

I'm not sure what's unclear about the comment... How about:

While the INSERT/DELETE is less efficient than single UPDATE,
the UPDATE only works if there's an existing record in the
events table. I.e. if you create a node and then enable the event
module, there will be no record in the event table, so the dates
cannot be changed.

Now I got it. So this explanation is better.

And yes, I don't care about windows.

bigbman, don't mind Killes, he's always a little bit crabby. I wouldn't say idiot, perhaps just brave ;) But seriously, Drupal should work on Windows. I do all my development on Windows machines and host on UNIX. Please keep reporting the bugs that you find. You're saving the next person the trouble.

Drewish, thanks for the hard work. In my case, I've decided not to apply the patch because I seem to have gotten rid of this problem by upgrading to PHP 5.1.1. I decided to give it a try because one of the improvements of 5.1.1 (implemented in 5.1.0 actually) is:

"- A complete rewrite of date handling code, with improved timezone support. "

And the rewrite seems to have worked very nicely. I'm not getting this warning anymore. I don't think I changed any of my settings, but of course I could be wrong.

Just for kicks, I reverted to the original event.module included in 4.6 and it's working just fine, so I decided to leave it as it was.

Thank you anyways for your hard work Drewish, it's very much appreciated.

Bigbman, you are not the only one trying to run Drupal on a windows system. There are plenty of us. And we are not idiots, in my case I just have to work within the constraints of my clients.

There is no reason why Drupal cannot work with windows (other than Gerhard not caring about windows, of course). I for one will try to be more active on the development side, if not doing actual development yet, at least reporting any bugs that I find in Windows.

diego_jarrin, I'm pretty sure all that the upgrade to 5.1.1 did was remove the warning message. The bug is and was in the event.module, you're just not seeing the warning related to it.

bigbman, what page are you looking at to get all those warnings?

Hmmm... Drewish, but the Event module seems to be working very well as far as I can tell. I've scheduled several events and they all appear to be ok.

Are you sure PHP 5.1.1. only got rid of the warning? It does say in the PHP website that it was a complete rewrite of the date functions...

diego_jarrin, well there are a few bugs mixed in together here. the big one is easy to reproduce:
* disable the event module
* create a node that is event enabled
* re-enable the event module
* try to set a date on the node created when the event module was disabled

the other bug is that the event_start and event_end variables aren't being correctly initialized by event_validate_form_date(). it's the one causing all the 1970 warnings. perhaps as part of the upgrade they've implemented support for negative timestamps on windows, i'm not really sure. either way the bug is still there.

i'm not sure what bigbman's latest bug is about, i'll have to have him insert some debug code for me to track it down.

attached is an 4.6 patch with the new comments and another correction to event_validate_form_date().

patch with updated comment for HEAD.

bigbman, grab a clean copy of event.module then apply the latest 4.6 patch. let me know how that works.

dude, install a copy of the cygutils/cygutils package. it's got two program called unix2dos and dos2unix to switch line endings.

This may not be what you were looking for, but I've followed the suggestions here, and it's been running fine for a few months now:

http://drupal.org/node/8212

bigbman, i don't want to waste time on this thread troubleshooting your bug. you need to enable the contact form on your profile page so i can contact you.

thanks, applied.

The original post cited the timestamp issue in common.inc. I encountered the same error when deleting a user who had submitted nodes. The inability to resolve the missing user assigned ID number caused the error. I fixed the problem by creating a user and manually changing the assigned ID number in MySQL to the original deleted value (I determined the missing ID number by looking in the node table and finding the offending nodes). Not programatically aesthetic but it worked.