Call to a member function getName() on a non-object in date api

There is no way to do anything with a random error message and no information about how to reproduce. There is no such error on a clean install, so you have some other module enabled that is causing this, probably.

Do all the usual debugging steps -- try it on a clean install, if you can't reproduce it there it is some other module. Add other modules to the clean install to try to identify which one triggers the problem. Try the dev version and see if that takes care of the problem. If so, it's already fixed.

No response. Closing.

This happens whenever I programmatically create a DateObject.

This is probably the same error I am getting: Fatal error: Call to a member function getName() on a non-object in /home/barriear/dev/public_html/sites/all/modules/date/date_api/date_api.module on line 286 (the line number is slightly higher)

In my setup I have selected the date contextual filter, and the error happens if I configure the filter 'Dates to compare' to 'Only this field'.

I do have an 'End date' for the field in question that is optional and can be NULL. I am not sure if this is the source of the problem.

Per #3, "This happens whenever I programmatically create a DateObject." Not enough information to reproduce the problem. There are dozens of possible ways you might create a date object and values you might try to put into it, no idea what you tried to do.

Per #4, "configure the filter 'Dates to compare' to 'Only this field'" apparently refers to some filter I've never seen that is not a part of this package. If you have a problem using another module, you should report an error there. If that's not it I need more information about what that filter is.

Either way, none of the reports here have information that would make it possible for me to reproduce the error, nor is there any error on a clean install using only the Date module, as far as I can see.

In the sentence that you quoted, a bit earlier I say this: "I have selected the date contextual filter". The quote you are refering to is talking about the configuration options of that filter. Upon investigating this further I now realize that I had made the mistake. The issue belongs to a different module that is also of your authorship: 'Calendar'. I will close this issue and post it in that queue. Again, thanks for your time to take to investigate this.

Small update. I can't seem to reproduce the error with a clean install, so it'll take a bit more digging to explain what's been done to cause the issue. Suffice it to say that it happens at least some of the time, and if that's the case, we can be sure that there is 'something' to resolve. That said, time is obviously a valuable commodity, so I will do what I can to weed this out. All in all, I believe the problem lies somewhere within the calendar module.

Sorry, I too can not specify the steps to replicate. It shows up occasionally when doing AJAX calls on non-date fields.

We have a massive complex system and of the 50 + times I have saved this particular content type, the issue has only arisen once for me, but AJAX errors have also been reported by the client.

Anyways, there is a logical error here:

    // If this tz was given as just an offset or the timezone
    // was invalid, we need to do some tweaking.
    if (!$this->getTimezone() || !preg_match('/[a-zA-Z]/', $this->getTimezone()->getName())) {

      // If the timezone name is an offset and the original
      // $tz has a name, use it. This happens if you pass in
      // a date string with an offset along with a specific timezone name.
      if (!preg_match('/[a-zA-Z]/', $this->getTimezone()->getName()) && preg_match('/[a-zA-Z]/', $tz->getName())) {
        $this->setTimezone($tz);
      }
      // If we get this far, we have no information about the timezone name,
      // but we will get undefined index errors without any name.
      else {
        $this->setTimezone(new DateTimeZone("UTC"));
        $this->errors['timezone'] = t('No valid timezone name was provided.');
      }
    }

ie.
!$this->getTimezone() is followed directly by $this->getTimezone()->getName().

So I guess this should be as either $this->getTimezone() is NULL and the second test has already failed:

      if (preg_match('/[a-zA-Z]/', $tz->getName())) {
        $this->setTimezone($tz);
      }

?>

I wonder if the Migrate Tests should be dropped until someone can get these working again...

lol, I have managed to trace this slightly better. It appears to be a '#limit_validation_errors' error and date repeat element #element_validate is triggering and all hell lets loose... well, some notices are thrown followed by a fatal error. (edit: I's laughing as '#limit_validation_errors' has been causing me a bit of grief in miscellaneous modules over the last couple months...)

To replicate (I haven't tried a clean install)

1. Add a Date repeat field, (with date & time and to & from components / with popup calendar) and a image field.
2. Enter a from / to date field with to date less than from date.
   Note, I just tested using different time components with the same date component; From "2013-05-20 11:00 PM" to "2013-05-20 12:30 PM".
3. If I press Submit, no problems, a standard validation message, no PHP notices / warnings.
4. Remove or add an image, (maybe any "add more items" button) and I get a potpourri of warnings (about 20) starting with:
   
   Warning: date_timezone_set(): The DateTime object has not been correctly initialized by its constructor in date_repeat_build_dates() (line 426 of sites\all\modules\date\date_repeat_field\date_repeat_field.module).
   
   Which would be followed by a fatal error if it wasn't for the above patch.

A couple of dpms() here showed that the validated date values were a mix of strings, an array and a DateTime object and this is where I stopped debugging as I would not have a clue where the values are being set, nor what values are correct. Having three different date structures appeared wrong.

  $item = drupal_array_get_nested_value($form_state['values'], $element['#parents'], $input_exists);
  $input = drupal_array_get_nested_value($form_state['input'], $element['#parents'], $input_exists);
dpm($item);
dpm($input);

The position of the fatal error is way down the list of notices, about the second last.

[edit] Forgot to mention that file_ajax_upload() was the page callback that triggered the notices, (an image field remove button)

I got the same error message when trying to export a calendar with the date_ical module. (The calendar was using a custom date field, which I *think* is important for this bug.)

Anyways: The patch in #8 solved the problem for me. Yay!

I'm not sure that this one test is enough to mark RTBC, but I'm giving it a try.

Alan D.'s patch (#8) is correct: we are constructing a date and its timezone, so acting upon $this->getTimezone() is inappropriate here.

I have a very simple test. The first line below is OK, the second line gives the error. (OK, it might not be in date_api's normal timerange....)

$date   = new DateObject('23:00');
$date   = new DateObject('24:00');

In this case, the $tz timezone is set in line 210:

    elseif (empty($tz)) {
      $tz = date_default_timezone_object();
    }

patch #8 works for me perfectly!

There are 4 rtbtc's so far for this simple patch that prevents a fatal PHP error in multiple different use cases.

Maintainers?

The first time I read through #8 I could see that it would fix the fatal error, but it wasn't obvious to me if it was the correct fix or merely deleting the code that was causing the symptoms, whatever the consequences.

Taking a closer look I can see that it is in fact the correct fix, but I don't think the comments explained what was happening very clearly. I've attached a new patch which makes the same changes, but replaces the comments in this section. To me the key point is that the outer if() detects incomplete data, and the contents do their best to complete that data.

Hopefully this makes the patch easier to review so we can get it committed.

#8 used to work for me, but now i get this error when adding a node with a date field:

Warning: DateTime::format(): The DateTime object has not been correctly initialized by its constructor in DateObject->format() (line 385 of /sites/all/modules/date/date_api/date_api.module).

but when i take the original unpatched date_api.module i get different error:

Fatal error: Call to a member function getName() on a non-object in /sites/all/modules/date/date_api/date_api.module on line 286

which kind of sucks, because this way my site is unusable now... any ideas what to do?

after going back BEFORE updating many modules (but NOT date module) it seems to work again...
i have to find out first, which other module might cause this problem

Wow, holy white-screen, batman. This patch worked for me. It was triggered by another widget failing validation and attempting to kick back to a form_set_error.

Maintainers... ?

I am having the same issue as #16. Did anyone ever find a correction for this?

@ Mr Richards
Unfortunately not yet. I had no time to go through all the modules yet and so i just did not update it yet...
maybe i can do it tommorow...

#15 helped me. Please commit it.

I've committed the patch from #15. A new 7.x-2.x-dev should be out soon.

Thanks Peter!

The patches shared here were not working and causing some other warnings to creep up.
I have added the following check in constructor and that has removed all errors

// Store the raw time input so it is available for validation.
+ if(is_null($time))
+ return;

For my case this error was coming every time when date field has not been selected by user. This check has taken care of all warnings that were coming ..

@mahimajulka
The patch here stops the fatal error that nukes the site in one way or another.

The root bug is varied and individual tickets should be created to describe the various issues that trigger this, with steps to replicate on a clean installation.

i.e something like the steps in comment #10 above which I never followed up on as the end result was harmless PHP notices / warnings that were never shown and the Date results themselves within the AHAH call were never saved to the DB.

I don't know if this is of any interest but I encountered the following error message "Fatal error: Call to a member function getName() on a non-object in /home/softfish/public_html/alvi/sites/all/modules/date/date_api/date_api.module on line 286" when I used an invalid timezone parameter. I set the value of either date_default_timezone or (less likely) the timezone of user id 1 to "Melbourne/Australia" rather than the correct "Australia/Melbourne". When I then tried to enable the date_api function of the date module the message appeared. When I corrected the value for the timezone the error no longer occurred.

I think that is known as a GIGO issue. I would recommend using a select list of timezones to avoid such issues :)