Oups... phpDox encountered a problem and has terminated!

[m1ket]

Hello,

I'm having an issue setting up my Jenkins installation where phpdox keeps failing. Has anyone experienced this issue before?

phpdox:
     [exec] 
     [exec] 
     [exec] Oups... phpDox encountered a problem and has terminated!
     [exec] It most likely means you've found a bug, so please file a report for this and paste the stacktrace (if given) along!
     [exec] 
     [exec] Exception: ErrorException
     [exec] Location: /usr/share/pear/TheSeer/phpDox/shared/Version.php (Line 61)
     [exec] 
     [exec] date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead
     [exec] 
     [exec] #0 /usr/share/pear/TheSeer/phpDox/shared/Version.php(61): date()
     [exec] #1 /usr/share/pear/TheSeer/phpDox/CLI.php(178): TheSeer\phpDox\Version::getInfoString()
     [exec] #2 /usr/share/pear/TheSeer/phpDox/CLI.php(151): TheSeer\phpDox\CLI->showVersion()
     [exec] #3 /usr/bin/phpdox(60): TheSeer\phpDox\CLI->run()
     [exec] 
     [exec] 
     [exec] 
     [exec] Result: 1

[theseer]

This is not a bug or issue with phpDox but with your general PHP installation, as the error message shows:

date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting 
or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this 
warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead

Simply adjust the php.ini to contain a valid timezone setting.

[tag]

While I agree this can be resolved by setting date.timezone in the php.ini, I too encountered this issue.

It's a problem, because there is no default value set for date.timezone in php.ini, and libraries should anticipate that.

I know you closed this, but I believe it's a bug, as this result is avoidable by the phpdox.

[theseer]

Thank you for your thoughts.

phpDox is not a library but a tool that requires a sane configuration of its environment to be successful in its work. While I do understand that not having a default setting in php.ini might pose a problem phpDox is far from being the only application or case affected. Every request to any PHP script is likely to trigger this.

I do agree though that phpDox could handle this - as well as some other errors - more nicely. Read: Exit with a more descriptive error message rather than "crash"

The situation itself cannot really be avoided as there is no reliable way of getting the current timezone: I could, as many frameworks do, simply add a date_default_timezone_set( @ date_default_timezone_get()), but that would in best of all cases simply suppress the error and resolve to an arbitrary timezone setting.

[tag]

I may have some time in December to work on a patch, if there is a particular approach you'd like me to follow, whether it be noting the necessary configuration in the documentation, implementing a default time zone (which you seem to not want to do), or something a bit more complex.

Let me know how you'd like me to proceed, if at all.

[theseer]

It's not so much about the work as technically it comes down to simply not using the @ on the get and catching the ErrorException. That's not a big deal and I might actually implement it - or you can submit a PR for that.

What bothers me is that this approach would merely cover up the real problem and will most certainly cause new bug reports about phpDox being off by whatever hours in its log output.

[theseer]

Btw: PHP by default, if all other methods fail, will use UTC as the timezone. Which is about the least likely to be correct for anybody ;p

[theseer]

Okay, implemented a check into the preBootstrap code with commit d21603e to handle this issue explicitly.

[theseer]

For the record: The behavior changed for 0.8.0+ to explicitly use PHP's fallback to UTC when the configuration is missing. I'm still not happy with that but it's at least consistent with PHPs behavior.