diff mbox

php.ini: set date.timezone to UTC

Message ID 1430503955-24928-1-git-send-email-bos@je-eigen-domein.nl
State Superseded
Headers show

Commit Message

Floris Bos May 1, 2015, 6:12 p.m. UTC
Prevent a warning being logged each time a PHP date/time method is
used by setting UTC as (default) timezone in php.ini

Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
---
 package/php/php.mk | 1 +
 1 file changed, 1 insertion(+)

Comments

Arnout Vandecappelle May 1, 2015, 10:23 p.m. UTC | #1
On 01/05/15 20:12, Floris Bos wrote:
> Prevent a warning being logged each time a PHP date/time method is
> used by setting UTC as (default) timezone in php.ini
> 
> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
> ---
>  package/php/php.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/php/php.mk b/package/php/php.mk
> index 3b9a117..7bd3f63 100644
> --- a/package/php/php.mk
> +++ b/package/php/php.mk
> @@ -288,6 +288,7 @@ define PHP_INSTALL_FIXUP
>  	rm -f $(TARGET_DIR)/usr/bin/phpize
>  	$(INSTALL) -D -m 0755 $(PHP_DIR)/php.ini-production \
>  		$(TARGET_DIR)/etc/php.ini
> +	$(SED) 's/;date.timezone =/date.timezone = UTC/' $(TARGET_DIR)/etc/php.ini

 Would it be possible to use BR2_TARGET_LOCALTIME (if set) instead? Something like:

ifeq ($(BR2_TARGET_LOCALTIME),)
PHP_LOCALTIME = UTC
else
PHP_LOCALTIME = $(BR2_TARGET_LOCALTIME)
endif

	$(SED) 's%;date.timezone =.*%date.timezone = $(PHP_LOCALTIME)%' \
		$(TARGET_DIR)/etc/php.ini

 That is, assuming that php can deal with complex timezones like Europe/Brussels.

 Regards,
 Arnout

>  endef
>  
>  PHP_POST_INSTALL_TARGET_HOOKS += PHP_INSTALL_FIXUP
>
Floris Bos May 1, 2015, 11:08 p.m. UTC | #2
On 05/02/2015 12:23 AM, Arnout Vandecappelle wrote:
> On 01/05/15 20:12, Floris Bos wrote:
>> Prevent a warning being logged each time a PHP date/time method is
>> used by setting UTC as (default) timezone in php.ini
>>
>> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>> ---
>>   package/php/php.mk | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/package/php/php.mk b/package/php/php.mk
>> index 3b9a117..7bd3f63 100644
>> --- a/package/php/php.mk
>> +++ b/package/php/php.mk
>> @@ -288,6 +288,7 @@ define PHP_INSTALL_FIXUP
>>   	rm -f $(TARGET_DIR)/usr/bin/phpize
>>   	$(INSTALL) -D -m 0755 $(PHP_DIR)/php.ini-production \
>>   		$(TARGET_DIR)/etc/php.ini
>> +	$(SED) 's/;date.timezone =/date.timezone = UTC/' $(TARGET_DIR)/etc/php.ini
>   Would it be possible to use BR2_TARGET_LOCALTIME (if set) instead? Something like:
>
> ifeq ($(BR2_TARGET_LOCALTIME),)
> PHP_LOCALTIME = UTC
> else
> PHP_LOCALTIME = $(BR2_TARGET_LOCALTIME)
> endif
>
> 	$(SED) 's%;date.timezone =.*%date.timezone = $(PHP_LOCALTIME)%' \
> 		$(TARGET_DIR)/etc/php.ini
>
>   That is, assuming that php can deal with complex timezones like Europe/Brussels.

PHP used to use the system's time zone name automatically in older PHP 
versions.
But nowadays fills your log with warnings that is not reliable:

==
Warning: strtotime(): 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 the timezone 'UTC' for 
now, but please set date.timezone to select your timezone.
==

It certainly does work for common names like Europe/Brussels, but not 
sure if that goes for every zone name.


Yours sincerely,

Floris Bos
Arnout Vandecappelle May 2, 2015, 7:49 a.m. UTC | #3
On 02/05/15 01:08, Floris Bos wrote:
> On 05/02/2015 12:23 AM, Arnout Vandecappelle wrote:
>> On 01/05/15 20:12, Floris Bos wrote:
>>> Prevent a warning being logged each time a PHP date/time method is
>>> used by setting UTC as (default) timezone in php.ini
>>>
>>> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>>> ---
>>>   package/php/php.mk | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/package/php/php.mk b/package/php/php.mk
>>> index 3b9a117..7bd3f63 100644
>>> --- a/package/php/php.mk
>>> +++ b/package/php/php.mk
>>> @@ -288,6 +288,7 @@ define PHP_INSTALL_FIXUP
>>>       rm -f $(TARGET_DIR)/usr/bin/phpize
>>>       $(INSTALL) -D -m 0755 $(PHP_DIR)/php.ini-production \
>>>           $(TARGET_DIR)/etc/php.ini
>>> +    $(SED) 's/;date.timezone =/date.timezone = UTC/' $(TARGET_DIR)/etc/php.ini
>>   Would it be possible to use BR2_TARGET_LOCALTIME (if set) instead? Something
>> like:
>>
>> ifeq ($(BR2_TARGET_LOCALTIME),)
>> PHP_LOCALTIME = UTC
>> else
>> PHP_LOCALTIME = $(BR2_TARGET_LOCALTIME)
>> endif
>>
>>     $(SED) 's%;date.timezone =.*%date.timezone = $(PHP_LOCALTIME)%' \
>>         $(TARGET_DIR)/etc/php.ini
>>
>>   That is, assuming that php can deal with complex timezones like
>> Europe/Brussels.
> 
> PHP used to use the system's time zone name automatically in older PHP versions.
> But nowadays fills your log with warnings that is not reliable:
> 
> ==
> Warning: strtotime(): It is not safe to rely on the system's timezone settings.

 Any idea _why_ it is not safe? I've tried to google it but didn't come up with
a reason, just a lot of fixes.

> 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 the timezone 'UTC' for now, but please set date.timezone
> to select your timezone.
> ==
> 
> It certainly does work for common names like Europe/Brussels, but not sure if
> that goes for every zone name.

 Hm, php (like so often) has its own re-implementation of the timezone
database... . It's based on the same Olson database so it's probably OK for
valid timezones, but tzdata has additional posix/ and right/ variants and it
also has the old SystemV/ timezones...

 Well, people who use one of these weird timezones will see the php error so
they can solve it I guess.

 Regards,
 Arnout
Floris Bos May 2, 2015, 12:15 p.m. UTC | #4
On 05/02/2015 09:49 AM, Arnout Vandecappelle wrote:
> On 02/05/15 01:08, Floris Bos wrote:
>> On 05/02/2015 12:23 AM, Arnout Vandecappelle wrote:
>> == Warning: strtotime(): It is not safe to rely on the system's 
>> timezone settings. 
>   Any idea _why_ it is not safe? I've tried to google it but didn't come up with
> a reason, just a lot of fixes.

No idea.

>> 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 the timezone 'UTC' for now, but please set date.timezone
>> to select your timezone.
>> ==
>>
>> It certainly does work for common names like Europe/Brussels, but not sure if
>> that goes for every zone name.
>   Hm, php (like so often) has its own re-implementation of the timezone
> database... . It's based on the same Olson database so it's probably OK for
> valid timezones, but tzdata has additional posix/ and right/ variants and it
> also has the old SystemV/ timezones...
>
>   Well, people who use one of these weird timezones will see the php error so
> they can solve it I guess.

I do know Debian has a patch to let PHP use the system's timezone 
database instead of the internal one.
We could borrow that one, but then we would be deviating from upstream 
(which did not want the patch, and prefers to stick with their internal db).


Yours sincerely,

Floris Bos
Gustavo Zacarias May 2, 2015, 12:18 p.m. UTC | #5
On 05/02/2015 09:15 AM, Floris Bos wrote:

> I do know Debian has a patch to let PHP use the system's timezone
> database instead of the internal one.
> We could borrow that one, but then we would be deviating from upstream
> (which did not want the patch, and prefers to stick with their internal
> db).

As far as i remember it's a chicken-and-egg problem.
PHP is used in many old distros/systems that don't have modern tzdata
and that was a problem, so they bundled it (also cross-operating system
consistent behaviour).
But then the bundled one might be out of date as well, and takes up space :)
IMHO it should be a build-time php option.
Regards.
Floris Bos May 2, 2015, 3:09 p.m. UTC | #6
On 05/02/2015 09:49 AM, Arnout Vandecappelle wrote:
> On 02/05/15 01:08, Floris Bos wrote:
>> On 05/02/2015 12:23 AM, Arnout Vandecappelle wrote:
>>> On 01/05/15 20:12, Floris Bos wrote:
>>>> Prevent a warning being logged each time a PHP date/time method is
>>>> used by setting UTC as (default) timezone in php.ini
>>>>
>>>> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>>>> ---
>>>>    package/php/php.mk | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/package/php/php.mk b/package/php/php.mk
>>>> index 3b9a117..7bd3f63 100644
>>>> --- a/package/php/php.mk
>>>> +++ b/package/php/php.mk
>>>> @@ -288,6 +288,7 @@ define PHP_INSTALL_FIXUP
>>>>        rm -f $(TARGET_DIR)/usr/bin/phpize
>>>>        $(INSTALL) -D -m 0755 $(PHP_DIR)/php.ini-production \
>>>>            $(TARGET_DIR)/etc/php.ini
>>>> +    $(SED) 's/;date.timezone =/date.timezone = UTC/' $(TARGET_DIR)/etc/php.ini
>>>    Would it be possible to use BR2_TARGET_LOCALTIME (if set) instead? Something
>>> like:
>>>
>>> ifeq ($(BR2_TARGET_LOCALTIME),)
>>> PHP_LOCALTIME = UTC
>>> else
>>> PHP_LOCALTIME = $(BR2_TARGET_LOCALTIME)
>>> endif
>>>
>>>      $(SED) 's%;date.timezone =.*%date.timezone = $(PHP_LOCALTIME)%' \
>>>          $(TARGET_DIR)/etc/php.ini
>>>
>>>    That is, assuming that php can deal with complex timezones like
>>> Europe/Brussels.
>> PHP used to use the system's time zone name automatically in older PHP versions.
>> But nowadays fills your log with warnings that is not reliable:
>>
>> ==
>> Warning: strtotime(): It is not safe to rely on the system's timezone settings.
>   Any idea _why_ it is not safe? I've tried to google it but didn't come up with
> a reason, just a lot of fixes.

I just read: 
http://derickrethans.nl/distributions-please-dont-cripple-php-or-red-hat-stop-fucking-around.html

And the problem seem to just be that there isn't a standardized way to 
retrieve the exact timezone name set on a system, only derived information.
If you have Europe/London set on your system in the winter, PHP's old 
time zone detection algorithm would only be able to detect that it is 
currently "UTC" instead of that the timezone is set to London.
I can imagine that indeed gives problems if you have PHP code that works 
with time and date values in the past or future, and needs to take into 
account day light savings time.

That means there are only problems with the detection, and not really 
with the time zone names (except the exotic ones).
And there should be no problem just specifying BR2_TARGET_LOCALTIME in 
php.ini like you suggested.
diff mbox

Patch

diff --git a/package/php/php.mk b/package/php/php.mk
index 3b9a117..7bd3f63 100644
--- a/package/php/php.mk
+++ b/package/php/php.mk
@@ -288,6 +288,7 @@  define PHP_INSTALL_FIXUP
 	rm -f $(TARGET_DIR)/usr/bin/phpize
 	$(INSTALL) -D -m 0755 $(PHP_DIR)/php.ini-production \
 		$(TARGET_DIR)/etc/php.ini
+	$(SED) 's/;date.timezone =/date.timezone = UTC/' $(TARGET_DIR)/etc/php.ini
 endef
 
 PHP_POST_INSTALL_TARGET_HOOKS += PHP_INSTALL_FIXUP