Bug #54481 [Bgs]: date_default_timezone_get() returns incorrect timezone

2011-04-08 Thread stuart at horuskol dot net 
Edit report at http://bugs.php.net/bug.php?id=54481&edit=1

 ID: 54481
 User updated by:stuart at horuskol dot net
 Reported by:stuart at horuskol dot net
 Summary:date_default_timezone_get() returns incorrect
 timezone
 Status: Bogus
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux/Ubuntu
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I don't quite see why this is not a bug...



Why, when I own my server(s) and want to be able to have a single point
of configuration for timezones on that server (because of interoperating
services like PHP and MySQL) instead of sharded configuration in
separate files, can I not rely on my system timezone?



In addition - since the error is because I don't have default timezone
set - something is going wrong with the request to the server for the
timezone.



If you won't fix it, fair enough, but I don't think this is bogus.


Previous Comments:

[2011-04-08 11:40:03] der...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The guessing algorithm isn't perfect, that's why you *need* to make the
date.timezone setting in php.ini. You will also get a warning when it's
not set:



derick@whisky:~$ php -n -r 'echo date_default_timezone_get(), "\n";'



Warning: date_default_timezone_get(): 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/London'
for 'BST/1.0/DST' instead in Command line code on line 1

Europe/London



So make sure you have display_errors on as well, as well as set
error_reporting to include warnings. I've updated the documentation to
reflect this.


[2011-04-08 11:39:12] der...@php.net

Automatic comment from SVN on behalf of derick
Revision: http://svn.php.net/viewvc/?view=revision&revision=310049
Log: - Clarify the guessing stage of date_default_timezone_get() a bit
to prevent bug reports such as #54481.

----------------
[2011-04-07 04:21:10] stuart at horuskol dot net

Description:

We noticed a discrepancy between PHP and the server timezones, and found
that one four different servers (with two different versions of PHP -
5.2.4 and 5.3.2) the server was set to Australia/Adelaide (ACST), but
this date_default_timezone_get() was returning Asia/Jayapura (EIT).



There is no value in date.timezone (it is commented out) in the CLI and
Apache PHP configuration files - so according to the documentation, PHP
should be getting the timezone from the server configuration.



Why is it getting this random Asia/Jayapura value?



---

>From manual page:
http://www.php.net/function.date-default-timezone-get#Description

---

Test script:
---
echo date_default_timezone_get();

Expected result:

The correct timezone - not Asia/Jayapura when the server is set to
Australia/Adelaide

Actual result:
--
Asia/Jayapura






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=54481&edit=1

[PHP-BUG] Bug #54481 [NEW]: date_default_timezone_get() returns incorrect timezone

2011-04-06 Thread stuart at horuskol dot net 
From: 
Operating system: Linux/Ubuntu
PHP version:  Irrelevant
Package:  Date/time related
Bug Type: Bug
Bug description:date_default_timezone_get() returns incorrect timezone

Description:

We noticed a discrepancy between PHP and the server timezones, and found
that one four different servers (with two different versions of PHP - 5.2.4
and 5.3.2) the server was set to Australia/Adelaide (ACST), but this
date_default_timezone_get() was returning Asia/Jayapura (EIT).



There is no value in date.timezone (it is commented out) in the CLI and
Apache PHP configuration files - so according to the documentation, PHP
should be getting the timezone from the server configuration.



Why is it getting this random Asia/Jayapura value?



---

>From manual page:
http://www.php.net/function.date-default-timezone-get#Description

---

Test script:
---
echo date_default_timezone_get();

Expected result:

The correct timezone - not Asia/Jayapura when the server is set to
Australia/Adelaide

Actual result:
--
Asia/Jayapura

-- 
Edit bug report at http://bugs.php.net/bug.php?id=54481&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54481&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54481&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=54481&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54481&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=54481&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54481&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=54481&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=54481&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=54481&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=54481&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=54481&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=54481&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=54481&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54481&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=54481&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54481&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=54481&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=54481&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=54481&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=54481&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=54481&r=mysqlcfg

Bug #53035 [Com]: finfo_file() returns incorrect mimetype

2010-10-12 Thread stuart at horuskol dot net 
Edit report at http://bugs.php.net/bug.php?id=53035&edit=1

 ID: 53035
 Comment by: stuart at horuskol dot net
 Reported by:stuart at horuskol dot net
 Summary:finfo_file() returns incorrect mimetype
 Status: Bogus
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux/Ubuntu 10.04
 PHP Version:Irrelevant
 Block user comment: N

 New Comment:

"however, the command line tool 'mimetype' correctly identifies the file
using the same library at '/usr/share/misc/magic'"



I tested using the -M switch (as in my example/test script):



mimetype -DM --database /usr/share/misc/magic /path/to/file/reset.css



and this tells me the file is text/css on my platform - are you sure
you're using the same magic database?


Previous Comments:

[2010-10-12 07:52:11] ahar...@php.net

I get the same result from the command line "file" program on Ubuntu
10.10:



$ curl -s http://horuskol.net/reset.css | file --mime-type -

/dev/stdin: text/x-c



mimetype also believes it's C source:



$ mimetype -DM reset.css 

> Data dirs are: /home/aharvey/.local/share, /usr/share/gnome,
/usr/local/share, /usr/share

> Checking all magic rules

> Value "/*" at offset 2 matches at /usr/share/mime/magic line 1136

reset.css: text/x-csrc



The only way I can get mimetype to return text/css is if it also looks
at the extension (ie is called without -M).



I can't really see any way this is a PHP bug, given other programs using
the same magic database are resulting in the same file being detected as
C source. Closing.


[2010-10-11 15:39:35] fel...@php.net

Strange... It's caused by the comment in the begin of the CSS file.

----------------
[2010-10-10 13:37:04] stuart at horuskol dot net

Description:

This is tested on:

PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010
13:49:46)



file_info() is reporting a CSS file has having the mimetype 'text/x-c'
instead of 'text/css'



however, the command line tool 'mimetype' correctly identifies the file
using the same library at '/usr/share/misc/magic'



the file being tested is available at http://horuskol.net/reset.css

Test script:
---
PHP:



$finfo = new finfo(FILEINFO_MIME);

var_dump($finfo->file('/path/to/file/reset.css'));



$finfo = new finfo(FILEINFO_MIME, '/usr/share/misc/magic');

var_dump($finfo->file('/path/to/file/reset.css'));



$finfo = finfo_open(FILEINFO_MIME, '/usr/share/misc/magic');

var_dump(finfo_file($finfo, '/path/to/file/reset.css'));





Command Line:



mimetype -DM --database /usr/share/misc/magic /path/to/file/reset.css

Expected result:

string(26) "text/css; charset=us-ascii"

Actual result:
--
string(26) "text/x-c; charset=us-ascii"








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=53035&edit=1

[PHP-BUG] Bug #53035 [NEW]: finfo_file() returns incorrect mimetype

2010-10-10 Thread stuart at horuskol dot net 
From: 
Operating system: Linux/Ubuntu 10.04
PHP version:  Irrelevant
Package:  Filesystem function related
Bug Type: Bug
Bug description:finfo_file() returns incorrect mimetype

Description:

This is tested on:

PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010
13:49:46)



file_info() is reporting a CSS file has having the mimetype 'text/x-c'
instead of 'text/css'



however, the command line tool 'mimetype' correctly identifies the file
using the same library at '/usr/share/misc/magic'



the file being tested is available at http://horuskol.net/reset.css

Test script:
---
PHP:



$finfo = new finfo(FILEINFO_MIME);

var_dump($finfo->file('/path/to/file/reset.css'));



$finfo = new finfo(FILEINFO_MIME, '/usr/share/misc/magic');

var_dump($finfo->file('/path/to/file/reset.css'));



$finfo = finfo_open(FILEINFO_MIME, '/usr/share/misc/magic');

var_dump(finfo_file($finfo, '/path/to/file/reset.css'));





Command Line:



mimetype -DM --database /usr/share/misc/magic /path/to/file/reset.css

Expected result:

string(26) "text/css; charset=us-ascii"

Actual result:
--
string(26) "text/x-c; charset=us-ascii"



-- 
Edit bug report at http://bugs.php.net/bug.php?id=53035&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53035&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53035&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53035&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53035&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53035&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53035&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53035&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=53035&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=53035&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=53035&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=53035&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=53035&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=53035&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53035&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=53035&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53035&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=53035&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=53035&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=53035&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=53035&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=53035&r=mysqlcfg