Home » Date and Time » Date » Bug #1695
wrong time initialization for pseudo-null parameters
Details
| Submitted | 2004-06-21 16:10 UTC |
|---|---|
| From | christophe dot laratte at laposte dot net |
| Assigned | pajoye |
| Status | Bogus |
| Package | Date |
| PHP Version | 1.4.3 |
| OS | windows |
| Roadmaps | (Not assigned) |
Comments
[2004-06-21 16:10 UTC] christophe dot laratte at laposte dot net
Description:
------------
When you create a new Date class with a pseudo-null parameter, initialization is wrong twice times :
ie: $test=new Date('');
- the '' parameter is not null for is_null() function, so the $this->setDate($date) is used to init values.
- even with a real null parameter ($test=new Date();), the initialization of values is wrong, because there is no take care of timezone.
[2004-06-21 16:58 UTC] pierre at dotgeek dot org
Thank you for taking the time to write to us, but this is not
a bug.
Hello,
The docs say: "A date optionally passed in may be in the ISO 8601, TIMESTAMP or UNIXTIME format, or another Date object".
An empty string is none of them and not null.
About the TZ issue when no arg are passed, the constructor gets always the default TZ.
Please, provide the Date version in the next reports :)
--Pierre
[2004-06-28 16:37 UTC] christophe dot laratte at laposte dot net
Hello,
I confirm one of two bugs.
For the first (which is not a bug) :
I agree that pseudo-null (ie: '') is different from null (ie: null) and that the Date class interpretation is correct (even if I consider it as too restrictive).
$test=new Date(''); has non sens result. But it's not important.
For the second bug (real bug), this is a short description with two suggestions :
$test=new Date(); initialize $test with current hour value without taking care of the DEFAULT TZ !!!
Try it with setting this before :
$_DATE_TIMEZONE_DEFAULT='UTC';
(if you are in a country with an offset ;-)
Here are two bug-fixed for Date initialization :
first (simple but bad) :
function Date($date = null)
{
$this->tz = Date_TimeZone::getDefault();
if (is_null($date))
{
$env_tz = "";
if(getenv("TZ"))
{
$env_tz = getenv("TZ");
}
$tz=$this->tz;
putenv("TZ=".$tz->id);
$this->setDate(date("Y-m-d H:i:s"));
putenv("TZ=".$env_tz);
}
elseif (is_a($date, 'Date'))
{
$this->copy($date);
}
else
{
$this->setDate($date);
}
}
It's a bad solution, because I directly use putenv without using ConvertTzbyId().
So, the second solution :
function Date($date = null)
{
global $hostTzId;
$this->tz = Date_TimeZone::getDefault();
if (is_null($date))
{
$this->setDate(date("Y-m-d H:i:s"));
$this->setTZbyID($hostTzId);
$this->convertTZbyID($tz->id);
}
elseif (is_a($date, 'Date'))
{
$this->copy($date);
}
else
{
$this->setDate($date);
}
}
But you have to know the system timezone by setting $hostTzId...
My Date version is 1.4.3.
And I got a question : have you project to rewrite inDaylightTime function in TimeZone class so as to use internal computation based on DST change dates array like there : http://www.twinsun.com/tz/tz-link.htm ?
[2004-08-25 11:16 UTC] pierre at dotgeek dot org
> I agree that pseudo-null (ie: '') is different from null
> (ie: null) and that the Date class interpretation is
> correct (even if I > consider it as
> too restrictive).
BC problem and consistency.
>$test=new Date(); initialize $test with current hour value > without taking care of the DEFAULT TZ !!!
It does (see Date/TimeZone.php, at the end of this file we initialized the default TZ, using either the global, PHP_TZ or env(TZ)).
There is no point to fetch system TZ info in Date itself. This is a job for Date/TimeZone. In which TZ are you? What's the problem with your TZ? If you set the default TZ to UTC, what else do you expect?
> have you project to rewrite inDaylightTime
> function in TimeZone class so as to use internal
> computation based on DST change dates array like there
Not really in pear::date but on its way for pecl/datetime, using this TZ database natively.
--Pierre
[2004-08-25 12:46 UTC] christophe dot laratte at laposte dot net
I maintain that initialization like this :
$test=new Date();
products a mistake and DO NOT take care of the timezone.
OK that timezone value is set in PEAR::Date, but the time is not initiated
correctly (and don't take care of the timezone) !
An exemple :
I am in France now. The timezone is UTC+2.
Local time is 14:34:00
so utc time is 12:34:00
everywhere in the world utc time is the same and is 12:34:00
So if I set :
$_DATE_TIMEZONE_DEFAULT='UTC';
and after I set :
$test=new Date();
the timezone in $test is UTC but time as been initiated at 14:34:00.
That's the mistake ! The time should have been initiated at 12:34:00 which is
the real current time in UTC timezone.
The mistake is the same whatever you set $_DATE_TIMEZONE_DEFAULT.
If I have computed the code somewhere else in the world where the timezone is
different and I don't know it, I can't have an idea of the result.