call to unidentified function timezone_identifiers_list()

You need to enable the Date PHP4 module.

I'm getting a lot of these kind of reports, so I guess I need to do an auto-enable of that module somehow. I need to think about the best way to do it.

I receive a similar error which I think is Date PHP 4 related but I can't get onto the modules page to enable it first.

Fatal error: Call to undefined function: timezone_identifiers_list() in /home/thegreat/public_html/community/sites/all/modules/date/date_timezone/date_timezone.install on line 213

That's what I meant by 'auto-enable', the problem is figuring out where to do it to catch it before errors are thrown. I just committed a check in hook_init() that will turn it on if needed. We'll have to see if that catches it in the right place.

I found the source of this problem and just committed a fix. There is a call to timezone_identifiers_list() in the global space that gets triggered before we can do anything about checking versions or including files. I changed the way that was set up, then tested a PHP 4 install by trying to install a module with multiple dependencies without any of the dependent modules being available and everything was properly installed with no error messages.

Just FYI, for those locked out of their sites, the SQL statement UPDATE system SET status = 1 WHERE name = 'date_php4'; in PHPMyAdmin or from MySQL command-line will get you back.

However, the checking that KarenS put in apparently isn't working, because we ran into this same error today. :(

Fatal error: Call to undefined function: timezone_open() in /sites/all/modules/date/date_api.module.

What version are you using? There have been lots and lots of changes since beta2.

Good point. :)

I did some digging in the code. I see that in hook_requirements() you're checking for PHP version 5.2 and auto-enabling the Date PHP4 module if it doesn't exist.

The particular situation here was the client was working off localhost, which was running PHP 5.2.6. Everything worked great, and this check passed when Date API module was enabled. Then, they moved to the live server which was running PHP 5.1.6, and resulted in the error.

I have a feeling this is a "won't fix" issue though, because the only alternative you have is checking on hook_init() on *every* page load.

I did have this in hook_init() at one point and decided that was way too much for something that basically just needs to be done once.

Actually I'm not auto-enabling it in hook_requirements, just warning about it. I auto-enable it in hook_install() and hook_enable(). I suppose I *could* auto enable it in hook_requirements(), but by that time there will be an error message, so I don't know if it will help to add it there.

I think the main problem is that you can go along for quite a while with errors in hook_requirements without ever noticing them, since they only show up in a couple places.

What do you think, does this need a different solution or is the current one sufficient?

I guess we'll go with "won't fix" :)

Looks like this bug is still floating around in the latest version. - 2.4

After ensuring PHP 4 is enabled though it seems to be working fine.

Just need to make sure that before migrating all of the Date related modules are disabled and then re-enable them after migrating, making sure that PHP 4 is enabled.

Need to read the instructions a bit more when it says for everything pre 5.2, including 5.1.x

Thanks for the thoughts in this issue thread, it's been helpful!