Strict warning: Declaration of DateObject::setTimezone() ...

I think this is fixed by the patch at #969344: date_api_filter_handler->default_value() calls date_default_timezone(), not date_default_timezone_object().

I tried the patch in the link given in #1 and I still get the error:

Strict warning: Declaration of DateObject::setTimezone() should be compatible with that of DateTime::setTimezone() in drupal_load(). Any other way to fix the problem (Don't think that patch did anything to fix it).

I cannot see this error anywhere. I changed my error handling to strict and still don't see it, certainly not on every page request. I need steps to reproduce.

OK. Thanks for the response. I will get a report for you sometime tonight.

Here we go. To (hopefully reproduce), do the following exactly as it is written.

1. Download D7.x-dev
2. Download date-7.x-1.x-dev
3. In mysql 5.1, make sure strict mode is set to on.
- I can't confirm ATM with my webhost if their server is set with strict on right now, but assume it is since I get the same error from them as well.
4. Create an empty database for the test
5. Extract the drupal 7 dev gz archive into a web root somewhere.
6. Extract date-7.x-1.x-dev into the modules folder.
7. Start the installer as normal
- Choose profile (standard).
- Choose language (English [the only choice]).
- Fill out the database setup form according to your database name, username, password and host settings.
- After install, fill in the site configuration form and save.
8. Go to modules from the admin toolbar
9. Check the box to enable the date module
10. Click save configuration.
11. When asked, agree to enable the DateAPI module and click continue.

When the modules list comes back, I have the following errors:

Strict warning: Declaration of DateObject::setTimezone() should be compatible with that of DateTime::setTimezone() in drupal_load() (line 935 of C:\Documents and Settings\Andy B\My Documents\Web projects\d7\includes\bootstrap.inc).
Strict warning: Declaration of DateObject::setTimezone() should be compatible with that of DateTime::setTimezone() in drupal_load() (line 935 of C:\Documents and Settings\Andy B\My Documents\Web projects\d7\includes\bootstrap.inc).

I don't exactly know how to turn off strict mode, but I wonder if this might be causing the problem. It couldn't be if those functions have nothing to do with database code. Anyways, follow this and let me know if you get the same problems. If not, we might have to dig around more and find out what might be going on.

I'm also seeing this warning when using php.ini settings to "E_ALL | E_STRICT"
Strict warning: Declaration of DateObject::setTimezone() should be compatible with that of DateTime::setTimezone() in drupal_load() (line 935 of /home/lmontgomery/workspace/kairion/server/htdocs/includes/bootstrap.inc).

UPDATE: I see the issue whether running a 2-week-old dev snapshot (of Date) or the latest dev snapshot.

I am running D7-RC2 and have very few other modules turned on. It should not be hard to reproduce this issue, but it was not visible until my error reporting was changed to "strict" in the php.ini files (cli & apache2); a team member reported the issue to me and I had to turn on "strict" mode to reproduce it; that was all.

It also shows up (on the command line) when updating our features-generated module to include the Date module as a dependency (and include a Date field in a content type). Indeed, if php error reporting is set to "strict" in the "cli" version of php.ini, the feature fails to be built.

Other details: We see the warning even when there is no content or content type making use of a Date field (i.e. just the Date API module is activated). Sometimes it's repeated twice; other times just once.

Subscribing

Putting this back in "active" status, since I think there is sufficient information, now, to reproduce.

Raising priority to "normal" since it will actually prevent a Features-generated module from being built if normal "developer-mode" settings are used in the php.ini configuration of error reporting, so it's non-trivial for our use case.

Changing the status to critical since other modules that depend on the date api fail to work when used/activated. An example is Calendar. Since Date api throws errors, so does calendar. Also changing the title to make it less confusing.

I have the same error, running latest date dev release and PHP 5.3.1. After changing date_api.module 199 line from

public function setTimezone(DateTimeZone $tz, $force = FALSE) {

to

public function setTimezone($tz, $force = FALSE) {

I am not getting any more that strict warning.

But according to http://www.php.net/manual/en/datetime.settimezone.php setTimezone declaration looks like

public DateTime DateTime::setTimezone ( DateTimeZone $timezone )

so somebody is wrong here, I guess php documentation or there were some changes in method declaration in different versions of PHP. Also it seems that DateTime::setTimezone should return DateTime object, at least according to doc so maybe there should be

return parent::setTimezone($tz);

on the end of method override.

Waiting until it makes it into dev before trying an update. If you install calendar, do you get calendar errors?

Yes I have tested yesterday and today latest views, date, calendar D7 versions and founded bunch of strict warning errors in all 3 modules.

Here is a patch that will fix all strict warming errors for date module (at least what I have founded for now).

And you will also need patches for calendar

http://drupal.org/node/999514#comment-3835102

and views

http://drupal.org/node/1000044#comment-3835052

With all 3 patches applied I am not getting any more strict warning errors.

I will continue testing and if I find more strict warning errors I will update patches.

I have set php error reporting to E_ALL | E_STRICT and still do not see these errors anywhere. It must require php 5.3 to see them.

Try using it with php 5.3.1 or later.

That's the problem, I need to develop so things work with PHP 5.2 (the 'officially-supported' version for D6 and D7), so I don't have 5.3 installed.

I am using PHP 5.3.1 and seeing this error very well, but even if you do not see them just check the code - all errors are mostly related with class methods overrides from views module that are not implemented correctly in date and calendar modules.

That's the problem, I need to develop so things work with PHP 5.2 (the 'officially-supported' version for D6 and D7), so I don't have 5.3 installed.

I must complain here. If method override signature is implemented with error you don't need to support unofficial PHP 5.3 in order to fix this. This are clearly errors, the only thing is that PHP 5.2 will silently ignore them, and PHP 5.3.1+ will report them - but they are still errors and can reproduce bugs.

Isn't there a way to test for the php version and then based on that create the function definitions that are causing problems?

I committed this. Hopefully this won't create problems in old versions of PHP, but I have no way to test that any more.

Oh, I just realized I don't have to worry about old version of PHP any more in D7, so we should be good.

What do you mean by an older version of php?

Recommended: PHP 5.2 for Drupal 5 and 6, PHP 5.3 for Drupal 7
Required: PHP version 4.4.0 or higher for Drupal 5 and Drupal 6, PHP 5.2.5 or higher for Drupal 7

Read more on http://drupal.org/requirements