Tickets :: Comment on [#9608] Add date_default_timezone_set to avoid E

* Your Email Address
* Spam protection	Enter the letters below: .__ . ,. ,. ..__ [ __ \./ \./ \ /[__) [_./ \| \| \/ [__)
Comment	>> These are actually pretty expensive calls, and there's no reason to >> do them every single time. The responsibility of configuring the >> default timezone is also, in my opinion, outside the responsibility >> of the Log package. Why do you feel like this should be done in >> Horde_Log? > > You're right, they are expensive (but mandatory) and it only needs to > be called once (but it needs to). I've added it there since I > couldn't find anywhere else where to add it and be 100% sure that > date would never be called without date_default_timezone_set being > previously called. I've seen this issue on Horde_Log happening in an > "intrusive" way in at least two different "actions": > horde/bin/db_migrate and while trying to use Imp. > > On horde/bin/db_migrate it is only annoying, and this one line in > that script will correct it. On the other hand, on IMP this message > appears in the alert popup's, and the calls made (for instance to see > the messages in one folder) have the E_WARNING returned instead of > the expected result, making IMP unusable: > > Post: > [...]/horde/services/ajax.php/imp/viewPort?checkcache=1&slice=1%3A91&view=INBOX > Response body: > /-secure-{"response":null,"msgs":[{"charset":"UTF-8","message":"DateTime::__construct(): 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 'Europe\/Paris' for 'WET\/0,0\/no DST' > instead","flags":[],"type":"horde.error"}]}*/ > > Once again, I believe that there might be a place (that I can try to > find out, if you think this is the way to go) on IMP to make the > date_default_timezone_set, but I'm afraid more places will have the > Logger calls without the previous date_default_timezone_set ... > > Anyway, please tell me how do you think this should be properly > fixed. If you think we should add this on what calls Logger and not > in Logger itself, I can work on submitting a patch to fix this issue > on the places I've found out using Logger this way.
Attachment
Watch this ticket

Saved Queries