[#10453] - Make sure $tz is an instance of DateTimeZone before attempting to create DateTime
- Closed
- 23 Sep 2018
- Medium
- Build: staging
- # 10453
- Diff
- paulgv:staging
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Error continuous-integration/jenkins/pr-merge This commit cannot be built Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #10451 .
Summary of Changes
Slightly modified libraries/joomla/date/date.php to prevent PHP fatal error when creating DateTime objects when $tz isn't correctly instantiated as a DateTimeZone object.
Testing Instructions
$date = new JDate('now', (int)1);
Throws PHP error :
DateTime::__construct() expects parameter 2 to be DateTimeZone, integer given
| Status | New | ⇒ | Pending |
| Labels |
Added:
?
|
||
| Title |
|
||||||
| Title |
|
||||||
| Title |
|
||||||
| Title |
|
||||||
brianteeman
- | Category | ⇒ | Libraries |
| Rel_Number | 0 | ⇒ | 10451 |
| Relation Type | ⇒ | Pull Request for |
Maybe this is already known, but I have a use case that could explain how this error is coming up. Old versions of Joomla (e.g. 1.5) used non-structured text content in the params field of the user table. This also includes using integers for timezones.
Example:
admin_language=
language=
editor=
helpsite=
timezone=-6
However, newer versions (e.g. 3.x) user structured data and text-based timezone data.
Example:
{"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":""}
In my case, we had migrated users from an older 1.5 site into a newer 3.x site and somewhere along the line didn't notice this difference. Didn't get an error until one of these older users tried to make an edit. Our newer users, including myself, had no trouble.
This can be remedied by something like this:
UPDATEj3x_usersSETparams='{"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":""}';
...which sets all users to use default CMS values. This may not work for your situation if users have set other values, as you will be overwriting them.
If this Issue get no Response, it will be closed at 22th September 2018.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 2018-09-23 05:16:04 | ⇒ | 2018-09-23 05:16:06 |
| Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-09-23 05:16:04 |
| Closed_By | ⇒ | franz-wohlkoenig |
| Status | Closed | ⇒ | Pending |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/10453
This has been closed due to lack of response to the requests above – it can always be reopened.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/10453.
I have not tested but it looks like, this PR will indeed suppress the exception error in cases that an integer is passed as timezone
something else is bogus and what this PR suggests is suppress the error created by some other bug (possibly by 3rd party extension or maybe it is CORE code ?), this way we may hide bugs in the future
please read my answer here:
#10451
but someone can argue that it is not important to use correct timezone in such cases,
and can argue that it is preferable to continue execution, despite bad timezone being passed ... aka make it more "fault tolerant", but "fault tolerant" is for cases such as interrupted communications, not for masking out other bugs