PEAR Bug Search Results

Date: Bug 20095 [Open] package requires none existent file

thomas at btspuhler dot com — 2013-10-14T03:37:28+00:00

Date Bug
Reported by spuhler
2013-10-14T03:37:28+00:00
PHP: Irrelevant OS: Linux Package Version: 1.5.0a4

Description:
------------
This pacakge requires
PEAR/PackageFileManager/Git.php

files  buildPackageXML.php contains the following line:
require_once 'PEAR/PackageFileManager/Git.php';
This file doesn't exist.

Date: Bug 19350 [Open] Date comparison broken for BST this year

pear at thedumbterminal dot co dot uk — 2012-03-26T17:20:07+00:00

Date Bug
Reported by dumb
2012-03-26T17:20:07+00:00
PHP: 5.3.10 OS: Linux Package Version: 1.5.0a2

Description:
------------
When comparing dates on 26/03/2012 before() and after() do not work as expected. This problem goes away after or before BST of this year.

Test script:
---------------
//Default timezone 	Europe/London 
require_once "Date.php";
$date = new Date("2012-03-26 10:46:17");
$compare = new Date("2012-03-26 00:00:00");
var_export($date->after($compare));
var_export($date->before($compare));

Expected result:
----------------
bool(true)
bool(false)


Actual result:
--------------
bool(false)
bool(true)

Date: Bug 18942 [Open] DateDiff calculation error

cliff at jcid dot nl — 2011-10-29T14:54:59+00:00

Date Bug
Reported by cmodijk
2011-10-29T14:54:59+00:00
PHP: 5.2.12 OS: CentOS Package Version: Unknown

Description:
------------
The date diff gives a wrong day count.
When coming from 2011-10-01 to 2011-11-01 it gives 32 days 
While if you diff 2011-08-01 to 2011-09-01 it gives 31 days



Test script:
---------------
$begin 					= new Date("2011-10-01");
$eind 					= new Date("2011-11-01");
echo $aantalDagen			= ceil($eind->dateDiff($begin));
// 32 # Needs to be 31

$begin 					= new Date("2011-08-01");
$eind 					= new Date("2011-09-01");
echo $aantalDagen			= ceil($eind->dateDiff($begin));>dateDiff($begin));
//  31 # Expected 

Expected result:
----------------
Expexted to get 31 in both cases

Actual result:
--------------
Got 32 an 31

Date: Bug 18417 [Open] Date_Span changes timezone silently

pear at thedumbterminal dot co dot uk — 2011-03-31T20:55:29+00:00

Date Bug
Reported by dumb
2011-03-31T20:54:03+00:00
PHP: 5.1.6 OS: Linux Package Version: 1.5.0a1

Description:
------------
When using Date_Span with the setFromDateDiff() method the 2 given Date objects will have their timezones siliently changed to UTC.

I understand that a date needs to be converted into UTC before any calculation is performed, but the state of the objects passed into the method should not be affected afterwards.

A Possible solution could be to clone the objects, then perform the timezone alteration and caculation on the clones. fialing that you could just change the times zones back after the calculations.

ps.
This is similar to:
http://pear.php.net/bugs/bug.php?id=6435&edit=2

But the problem is caused by:

Span.php:

function setFromDateDiff($date1, $date2)
    {
        if (!is_a($date1, 'date') or !is_a($date2, 'date')) {
            return false;
        }
        $date1->toUTC();
        $date2->toUTC();

..etc..

Expected result:
----------------
Before date span:
event1 info: 2011-03-31 16:44:59 Europe/London
event2 info: 2011-03-31 16:44:59 Europe/London
After date span:
event1 info: 2011-03-31 16:44:59 Europe/London
event2 info: 2011-03-31 16:44:59 Europe/London


Actual result:
--------------
Before date span:
event1 info: 2011-03-31 16:44:59 Europe/London
event2 info: 2011-03-31 16:44:59 Europe/London
After date span:
event1 info: 2011-03-31 15:44:59 UTC
event2 info: 2011-03-31 15:44:59 UTC

Date: Bug 18368 [Open] compare() modifies Objects

ehansmair at prompt-software dot de — 2011-03-17T19:18:57+00:00

Date Bug
Reported by ernst
2011-03-17T19:18:57+00:00
PHP: 5.2.12 OS: Windows 7 Package Version: 1.4.7

Description:
------------
The method compare($a,$b) normalizes the time zone to UTC before comparing. This should not be done on the operands, but on clones of the operands. Problem exists, if a time zone other than UTC is used.

I am using the Date in time zone CEST. A Date of 2011-01-01 00:00:00 is modified to 2010-12-31 23:00:00


Test script:
---------------
$a = new Date( '2011-01-01' );

print 'before: ' . $a->year;

$res = $a->compare( new Date('2011-01-01');

print 'after: ' . $a->year;

Expected result:
----------------
before: 2011
after: 2010

Date: Bug 18136 [Open] Method setDay can create invalid date

johnny dot cheng at free dot fr — 2010-12-22T16:53:12+00:00

Date Bug
Reported by jcheng
2010-12-22T16:53:12+00:00
PHP: 5.3.4 OS:  Package Version: 1.4.7

Description:
------------
Method setDay can create invalid date if we give a day that doesn't exist in the current month.

Test script:
---------------
$date = new Date('2010-02-15');
$date->setDay(31);
echo $date->getDate(DATE_FORMAT_ISO);

Expected result:
----------------
It's giving me 2010-02-31 but the returned date is not a valid one. I was expecting it to give me one of those valid dates :
- 2010-02-28
- the date advanced by 31 days (2010-03-04).
- the result of : echo date( 'Y-m-d', mktime(0, 0, 1, 2, 31, 2010) );

A possible patch would be :

    function setDay($d)
    {
        if ($d > 31 || $d < 1) {
            $this->day = 1;
        } else {
            $this->day = $this->getDaysInMonth() < $d ? $this->getDaysInMonth() : $d;
        }
    }

Date: Bug 16954 [Open] Issue with setDate() with unix timestamp argument

steve at tracepointgps dot com — 2009-12-28T10:24:09+00:00

Date Bug
Reported by steve_tp
2009-12-28T10:24:09+00:00
PHP: 5.2.1 OS: CentOS Package Version: 1.4.7

Description:
------------
setDate does not appear to behave correctly when setting with a unix timestamp.  It gets the timezones messed up.  I think I've tracked this down.  The following code appears in Date::setDate:

        } elseif (is_numeric($date)) {
            // UNIXTIME
           $this->setDate(date("Y-m-d H:i:s", $date));
        } else {

The problem is that this code always sets the time as local time, because that's what the php date() function returns, and the "Y-m-d H:i:s'  specifier does not include a GMT offset.  The line that invokes $this->setDate should be changed to:
           $this->setDate(date("c", $date));
Which will set the date in ISO standard format with the proper GMT offset.


Test script:
---------------
";
echo "This should returnn a GMT time of Tuesday, November 24th 2009, 12:47:31 +00:00
";

$alertTime = new Date();
$alertTime->setDate($timestamp);
$alertTime->setTZByID("GMT");

$alertTimeGMTString = $alertTime->format("%D %r %O");

$alertTime->convertTZByID($accountTimeZone);
$alertTimeLocalDate		= $alertTime->format("%D");
$alertTimeLocalDisplay	= $alertTime->format("%r");	
$alertTimeLocalString	= $alertTime->format("%D %r %O");
$tzAfter = getenv("TZ");
echo "

Alert timestamp: $timestamp, ($alertTimeGMTString) GMT,  Account TZ: $alertTimeLocalString
";
echo "
" .
				"Account timezone is: $accountTimeZone 
" .
				"Alert time GMT is: $alertTimeGMTString ($alertTimeGMT)
" .
				"Alert time local is: $alertTimeLocalString 
";
?>

Expected result:
----------------
Testing Date with a timestamp of 1259066851.
This should returnn a GMT time of Tuesday, November 24th 2009, 12:47:31 +00:00


Alert timestamp: 1259066851, (11/24/2009 12:47:31 PM +00:00) GMT, Account TZ: 11/24/2009 07:47:31 AM -05:00

Account timezone is: US/Eastern
Alert time GMT is: 11/24/2009 12:47:31 PM +00:00 ()
Alert time local is: 11/24/2009 07:47:31 AM -05:00 

Actual result:
--------------
Testing Date with a timestamp of 1259066851.
This should returnn a GMT time of Tuesday, November 24th 2009, 12:47:31 +00:00


Alert timestamp: 1259066851, (11/24/2009 07:47:31 AM +00:00) GMT, Account TZ: 11/24/2009 02:47:31 AM -05:00

Account timezone is: US/Eastern
Alert time GMT is: 11/24/2009 07:47:31 AM +00:00 ()
Alert time local is: 11/24/2009 02:47:31 AM -05:00

Date: Bug 16822 [Open] setTZByID() does not behave as expected

steve at tracepointgps dot com — 2009-11-23T01:49:57+00:00

Date Bug
Reported by steve_tp
2009-11-23T01:34:07+00:00
PHP: 5.2.5 OS: CentOS Package Version: 1.4.7

Description:
------------
Perhaps this is an expectation problem.  I instantiate a new Date object with a timestamp  $x = new Date(time());
and then set the timezone
$x->setTZByID("GMT");
I expect the timestamp  to remain the same, and the date to now be reported in GMT, but the date and time are now reported inconsistently.

Am I interpreting this wrong somehow?

Test script:
---------------
setTZByID("GMT");
$timestampGMT = $d->getTime();
echo "Local Time: " . date("m/d/Y h:i:s A O") . " timestamp = $timestamp 
";
echo "Time in GMT: " . $d->format("%D %r %O") . " timestamp = $timestampGMT 
";
?>

Expected result:
----------------
Local Time: 11/22/2009 02:34:07 PM -0500 timestamp = 1258918447
Time in GMT: 11/22/2009 07:34:07 PM +00:00 timestamp = 1258918447 

Actual result:
--------------
Local Time: 11/22/2009 02:34:07 PM -0500 timestamp = 1258918447
Time in GMT: 11/22/2009 02:34:07 PM +00:00 timestamp = 1258918447 

Note: on 2nd line, timestamp and time are now inconsidtent.

Date: Bug 16574 [Open] inDaylightTime fails for southern hemisphere DST

2009-09-07T15:41:18+00:00

Date Bug
Reported by morloch
2009-09-07T15:41:18+00:00
PHP: 5.2.1 OS: NA Package Version: 1.5.0a1

Description:
------------
For a date and time that is definitely in a valid daylight savings period, the inDaylightTime function incorrectly reports that the given time is not DST.

The logic on lines 761 and 762 appears to be at fault, it should be a logical OR, not AND.

Test script:
---------------
getID() . "\n";
var_dump($defaultZone->inDaylightTime($now));
echo $now->format('%Y-%m-%d %H:%M:%S%O') . "\n";
?>

Expected result:
----------------
Australia/ACT
bool(true)
2008-01-11 10:00:00+11:00

Actual result:
--------------
Australia/ACT
bool(false)
2008-01-11 10:00:00+10:00

Date: Bug 16520 [Open] Compare returns invalid result for certain dates due to standard time conversion

spencer at instantdelay dot com — 2009-09-26T22:32:02+00:00

Date Bug
Reported by svanhoose
2009-08-13T23:43:45+00:00
PHP: 5.2.5 OS: Irrelevant Package Version: 1.5.0a1

Description:
------------
The Date::compare function uses incorrect logic to compare two dates. It first gets the value of each date in days (without converting to standard time). If the days are equal, it goes on to check hours, minutes, etc. However, it uses getStandardHour, etc. for those comparisons. This can cause problems for dates near day boundaries where this conversion can cause the hours to rollover to the previous day.
e.g.

2009-08-07 10:00:00 and
2009-08-07 00:00:00
(both in America/Los_Angeles)

The # of days are equal, so hours must be compared. For the first date getStandardHour() returns 9. On the second date, getStandardHour() returns 23. This causes compare to return that the 1st date is before the 2nd.

Test script:
---------------
setTZByID("UTC-0800");
$d2->setTZByID("UTC-8000");

$result = Date::compare($d1, $d2);
echo "Is " . $d1->getDate() . " before " . $d2->getDate() . " ?\n";
echo ($result < 0 ? "Yes" : "No");
?>

Expected result:
----------------
The code should print No since obviously August 8th at 10 AM is not before August 8th at 12 AM.

Actual result:
--------------
The code prints Yes.

Date: Bug 16434 [Open] Date object incorrectly loaded with UTC date/time minus 2 hours

joebarh at yahoo dot com — 2009-07-13T17:34:11+00:00

Date Bug
Reported by joebarh
2009-07-13T17:34:11+00:00
PHP: 5.2.5 OS: Windows XP Package Version: 1.4.7

Description:
------------
D:\PHP528>pear version
PEAR Version: 1.8.1
PHP Version: 5.2.8
Zend Engine Version: 2.2.0
Running on: Windows NT xxxx 5.1 build 2600

I am based in Switzerland, TZ = Europe/Zurich

Problem is that the instance of Date I create is loaded with the UTC date/time minus 2 hours

interestingly enough, a dump of the object shows that internally the Date_TimeZone object is properly set to represent an UTC date/time

Test script:
---------------
require_once 'D:\PHP528\pear\Date.php';

// X-WR-TIMEZONE:Europe/Zurich
//20090606T190000Z   // gives 9pm Europe/Zurich
//20090607T000000Z     //gives 2am Europe/Zurich

$now = new Date("20090606T190000Z");   /Z means UTC

echo $now->getDate();

var_dump($now);

Expected result:
----------------
2009-06-06 19:00:00

Actual result:
--------------
2009-06-06 17:00:00


object(Date)#1 (9) { ["year"]=>  int(2009) ["month"]=>  int(6) ["day"]=>  int(6) ["hour"]=>  int(17) ["minute"]=>  int(0) ["second"]=>  int(0) ["partsecond"]=>  float(0) ["tz"]=>  object(Date_TimeZone)#3 (8) { ["id"]=>  string(3) "UTC" ["longname"]=>  string(26) "Coordinated Universal Time" ["shortname"]=>  string(3) "UTC" ["hasdst"]=>  bool(false) ["dstlongname"]=>  string(26) "Coordinated Universal Time" ["dstshortname"]=>  string(3) "UTC" ["offset"]=>  int(0) ["default"]=>  NULL } ["getWeekdayAbbrnameLength"]=>  int(3) }

Date: Bug 16352 [Open] Inconsistent time conversion on window and linux with DST

tomasm2005 at gmail dot com — 2012-01-27T19:40:28+00:00

Date Bug
Reported by tomasm2005
2009-06-20T11:45:55+00:00
PHP: 5.2.9 OS: Windows / Linux Package Version: Unknown

Description:
------------
While converting times from Los Angeles time to New Zealand time, if I use the time zone as 'New Zealand Standard Time', on Windows, DST is taken into account while on Linux, DST is not taken into account.

The bug disappears if the Date object is created as

$d = new Date(strtotime($date));

rather than

$d = new Date($date);

with the date being given in the format

YYYY-MM-DD HH:MM:SS


Test script:
---------------
http://pastebin.com/f5f2bd39e

Expected result:
----------------
Using New Zealand Standard Time : 2009-06-17 18:40:51

Using NZ : 2009-06-17 18:40:51

Actual result:
--------------
Using New Zealand Standard Time : 2009-06-17 19:40:51

Using NZ : 2009-06-17 18:40:51

( on linux)

Date: Bug 16299 [Open] [PATCH] Date_TimeZone::inDaylightTime had nasty side-effects due to altering TZ

mackstann at gmail dot com — 2009-06-06T06:20:44+00:00

Date Bug
Reported by mackstann
2009-06-06T06:20:44+00:00
PHP: 5.2.5 OS: Linux Package Version: 1.4.7

Description:
------------
inDaylightTime() alters the $TZ environment variable temporarily to do its calculation, and attempts to restore $TZ back to its original state, but does it wrong when $TZ was unset.  Instead of re-deleting it, it would set it to an empty string, which caused nasty side effects.

The fix is to re-unset it by doing putenv("TZ"), if it was originally unset.

Date: Bug 14852 [Open] DST in Time Zones for dates in past are inaccurate

mark at cyberspeedsolutions dot com — 2008-10-25T05:37:51+00:00

Date Bug
Reported by markeb
2008-10-22T20:40:21+00:00
PHP: 5.2.1 OS: Windows Package Version: 1.5.0a1

Description:
------------
The Daylight Saving Time adjustment of dates in the past is incorrect, whereas PHP's built-in DateTime class handles DST for dates in the past correctly.

It is reasonable to suggest that the PEAR Date_TimeZone class should be able to be modified to include the same Time Zone data as the core PHP v5.1+ DateTimeZone class (I assume this is publicly available via the core PHP source code).

ALSO, it is highly recommended that this be made a part of the PEAR Date_TimeZone core class so that it works on PHP versions before v5.1.

In my example, I used November 1, 2000 for the date along with a conversion from UTC to Eastern Time ('America/New_York' time zone).

Currently (as of 2008), November 1 DOES fall under Daylight Time. However, in the year 2000, November 1 was NOT under Daylight Time.

PEAR Date's conversion uses the *current* DST rules to make this Time Zone conversion instead of the DST rules that applied *at that time*. Note that PHP's core DateTime class (added in PHP v5.1) does NOT suffer this limitation.

Test script:
---------------
setTZById('UTC');
$date->convertTZById('America/New_York');
echo $date->getDate(),"\n";
echo "\n\n";

if ( version_compare(PHP_VERSION, '5.1', '>=') )
{
	$datet = new DateTime('2000-11-01 05:05:00 UTC');
	$datet->setTimeZone(new DateTimeZone('America/New_York'));
	echo $datet->format('Y-m-d H:i:s'),"\n";
}
?>


Expected result:
----------------
2000-11-01 00:05:00

2000-11-01 00:05:00

Actual result:
--------------
2000-11-01 01:05:00

2000-11-01 00:05:00

Date: Feature/Change Request 14770 [Open] If available, make use of PHP's DateTime tz information

daniel dot oconnor at gmail dot com — 2011-12-12T20:19:46+00:00

Date Feature/Change Request
Reported by doconnor
2008-10-09T14:40:38+00:00
PHP: 5.2.6 OS:  Package Version: CVS

Description:
------------
Consider looking for the DateTime extension, and using that functionality to get an up to date set of information on timezones; falling back to the current method.

This could be neatly implemented as a

Date_TimeZone_DataProvider // interface

Date_TimeZone_GenericProvider 
Date_TimeZone_DateTimeProvider
Date_TimeZone_UnitTestProvider


We have:
http://au.php.net/manual/en/function.timezone-transitions-get.php
http://au.php.net/manual/en/function.timezone-abbreviations-list.php

... which make this seem feasible.

This will also stop the slow trickle of:
Bug #14769 Bug #14389 Bug #14148 and lots, lots more.

Date: Bug 14769 [Open] Venezuela and Toronto time zones

jared dot becksfort at stjude dot org — 2008-10-23T18:51:19+00:00

Date Bug
Reported by jbcksfrt
2008-10-09T14:19:49+00:00
PHP: 5.2.1 OS: Debian Etch Package Version: 1.4.7

Description:
------------
Venezuela changed its time zone to be -0430 back in 2007.  The Linux zoneinfo file already reflects this and works with a zdump, but it is not respected by PEAR.  I assumed this is what Date_TimeZone uses until I noticed the _DATE_TIMEZONE_DATE array is what populates the offsets.  Can this make it into a release?  I did not see it mentioned in the current alpha.

I also noticed that America/Toronto is not in this array.   I just use Eastern/Canada for now, but it should probably included, as it is a valid UNIX time string (at least according to Wikipedia...).

Thank you!

Date: Feature/Change Request 14606 [Open] Extand with getNextMonth and getPrevMonth method

zerogiven at gmail dot com — 2008-09-06T12:20:47+00:00

Date Feature/Change Request
Reported by zerogiven
2008-09-06T12:20:47+00:00
PHP: 5.2.0 OS: Linux Package Version: 1.5.0a1

Description:
------------
I would really prefer a method where you get back a date object for the last or the next month.
I simply made that by copy the getNext and getPrevDate method and added or substract one month.
I send you my tested code so you can just copy and paste it if you want :)

Test script:
---------------
Attachments

Expected result:
----------------
get a DATE object with the next or the previous month from an existing DATE object

Actual result:
--------------
No method like this

Date: Bug 14434 [Open] Multiple calls to toUTC() weirdness

mark at sporkstorms dot org — 2010-07-09T13:21:17+00:00

Date Bug
Reported by sporkstorms
2008-08-01T11:00:32+00:00
PHP: 5.2.6 OS: Linux Package Version: 1.4.7

Description:
------------
When calling toUTC() multiple times on separate date objects it has 
inconsistent results. See the example script and output that follows.

Test script:
---------------
$time = new Date();
$time->toUTC();
echo $time->getDate() . "\n";

$time2 = new Date();
$time2->toUTC();
echo $time2->getDate() . "\n";



Expected result:
----------------
I'm not sure which is truly UTC.. so either:

2008-08-01 10:57:55
2008-08-01 10:57:55

OR

2008-08-01 03:57:55
2008-08-01 03:57:55





Actual result:
--------------
2008-08-01 03:57:55
2008-08-01 10:57:55

Date: Bug 14413 [Open] Passing a Unix timestamp in the constructor doesn't work (BC break)

mike at silverorange dot com — 2010-08-25T22:55:55+00:00

Date Bug
Reported by gauthierm
2008-07-28T13:45:45+00:00
PHP: 5.2.6 OS: Irrelevant Package Version: CVS

Description:
------------
The constructor hands off to setDate() which only parses Unix timestamps if the second parameter is set correctly. The constructor never passes the second parameter to setDate() when a Unix timestamp is passed.

Since there is ambiguity between ISO 8601 formatted dates like int(20080728) and Unix timestamps (int(20080728) is also a Unix time), a new optional parameter must be passed to the constructor to allow parsing Unix timestamps.

Test script:
---------------
getDate(DATE_FORMAT_ISO), "\n";

$date = new Date();
echo $date->getDate(DATE_FORMAT_ISO), "\n";
?>

Expected result:
----------------
2008-07-28 10:34:10
2008-07-28 10:34:10

Actual result:
--------------
0000-00-00 00:00:00
2008-07-28 10:34:10

Date: Bug 14389 [Open] Timezone Offsets Wrong

gopheryarrowzoo at googlemail dot com — 2008-07-26T15:09:38+00:00

Date Bug
Reported by gopheryarrowzoo
2008-07-22T19:35:53+00:00
PHP: 5.1.6 OS: CentOS Package Version: CVS

Description:
------------
All Timezones with Etc/GMT give the wrong expected result the time related fields like offset and 'name' fields.
noticed bug when trying to convert TimeZones from where my server is to 'localtime' anywhere in the world, trying with 'Etc/GMT' then the hours test script just shows quick example.


Test script:
---------------
include 'date/Timezone.php';
$tz_gmtminus12=&new Timezone('Etc/GMT-12');
print_r($tz);


Expected result:
----------------
Date_TimeZone Object ( [id] => Etc/GMT-12 [longname] => GMT-12:00 [shortname] => GMT-12:00 [hasdst] => [dstlongname] => GMT-12:00 [dstshortname] => GMT-12:00 [offset] => -43200000 [default] => )

Actual result:
--------------
Date_TimeZone Object ( [id] => Etc/GMT-12 [longname] => GMT+12:00 [shortname] => GMT+12:00 [hasdst] => [dstlongname] => GMT+12:00 [dstshortname] => GMT+12:00 [offset] => 43200000 [default] => )

Date: Bug 14151 [Verified] setDateTime references variables which are not passed to the method

philipp dot feigl at gmail dot com — 2008-07-21T12:57:34+00:00

Date Bug
Reported by pfeigl
2008-06-16T15:44:42+00:00
PHP: Irrelevant OS: CentOS Package Version: 1.5.0a1

Description:
------------
setDateTime references variables within its method body like $d, $m or $y, while the variables passed to the method are called differnt, like $pn_day, $pn_month, $pn_year.

Test script:
---------------
$date->setDateTime($day, $month, $year, $hour, $minute, $second);

Expected result:
----------------
setDateTime changes values of the date object

Actual result:
--------------
Error occurs, that the provided values are no valid date values

Date: Bug 14148 [Open] Offset for CEST seems to be incorrect

philipp dot feigl at gmail dot com — 2008-07-21T13:04:59+00:00

Date Bug
Reported by pfeigl
2008-06-16T13:12:16+00:00
PHP: 4.3.9 OS: CentOS Package Version: 1.5.0a1

Description:
------------
I've the following date setup on my machine:
Mon Jun 16 15:00:05 CEST 2008

CEST is the central european summer time, which is UTC+2, while in winter time we have CET, which it UTC+1.

However, when creating a new Date object from a UNIX timestamp (which was of course created in CEST), the resulting time is incorrect by one hour.

Setting the same sommertime setup for CEST as it exists for CET in the $GLOBALS['_DATE_TIMEZONE_DATA'] array seems to fixe the issue.

Test script:
---------------
format('%d.%m.%Y %H:%M:%S');
echo "\n";
echo date('d.m.Y H:i:s', $ts);
?>

Expected result:
----------------
16.06.2008 15:03:58
16.06.2008 15:03:58

Actual result:
--------------
16.06.2008 14:03:58
16.06.2008 15:03:58

Date: Bug 14042 [Open] Timezone conversion wrong

jmv at jmvware dot com — 2008-07-21T15:17:15+00:00

Date Bug
Reported by jmarcv
2008-06-02T02:25:38+00:00
PHP: 5.0.2 OS: red hat Linux Package Version: 1.5.0a1

Description:
------------
I don't know where else to put this - I get same result on 1.4 and this seems to be too obvious for it to still be around, but I just can't see what it is I am doing wrong.

Test script:
---------------
setTZByID('EST');
echo $date1->format('%Y-%m-%d %H:%M:%S'), ' ', $date1->tz->id, "
";
$date1->convertTZByID("GMT");
echo $date1->format('%Y-%m-%d %H:%M:%S'), ' ', $date1->tz->id, "
";
?>

Expected result:
----------------
2008-06-01 02:00:00 EST
2008-06-01 06:00:00 GMT

Actual result:
--------------
2008-06-01 02:00:00 EST
2008-06-01 07:00:00 GMT

Date: Feature/Change Request 13219 [Open] Methods like getNextDay() should check for complete data fields first

guenther dot stadler at gmx dot net — 2008-05-10T11:51:39+00:00

Date Feature/Change Request
Reported by estigy
2008-02-26T19:59:59+00:00
PHP: Irrelevant OS:  Package Version: 1.4.7

Description:
------------
There are many methods like getNextDay(), dayOfWeek() or daysInMonth() that should raise an error when the needed data fields (year, month, day,..) are not set to a meaningful value.

If the Date object is initialized with "2008-00-00", what is dayOfWeek() supposed to return?

At some point (directly at the initialization, or when calling of the calculation methods) there should be a warning that the return result simply has to be plain wrong, because there is not enough data to calculate it.

Test script:
---------------
$foo = new Date('2007-00-00');

var_dump($foo->getDayOfWeek());

Expected result:
----------------
* (bool) false
* PEAR_Error
* Exception
* ...

Actual result:
--------------
float(4)

Date: Feature/Change Request 10946 [Open] Date_Calc::dateFormat should default to DATE_CALC_FORMAT

daniel dot oconnor at gmail dot com — 2007-05-06T09:27:50+00:00

Date Feature/Change Request
Reported by doconnor
2007-05-06T09:27:50+00:00
PHP: 5.2.1 OS:  Package Version: 1.4.7

Description:
------------
If I do:

$formattedDate = Date_Calc::dateFormat(1, 1, 2007);

I get a blank string, which I would not expect, considering 99% of the other functions default to using DATE_CALC_FORMAT

examples:

function beginOfMonth($month = 0, $year = 0, $format = DATE_CALC_FORMAT)

function dateNow($format = DATE_CALC_FORMAT)

function daysToDate($days, $format = DATE_CALC_FORMAT)

function getCalendarYear($year = 0, $format = DATE_CALC_FORMAT)


Test script:
---------------
require_once 'Date/Calc.php';

var_dump(Date_Calc::dateFormat(1,1,2007));

Expected result:
----------------
20070101

Actual result:
--------------
empty string

Date: Bug 8912 [Assigned] putenv causes crashes in DateTimeZone::inDaylightTime under windows.

daniel dot oconnor at gmail dot com — 2009-01-01T08:52:18+00:00

Date Bug
Reported by doconnor
2006-10-09T01:33:36+00:00
PHP: 5.1.6 OS:  Package Version: 1.4.6

Description:
------------
putenv causes crashes in DateTimeZone::inDaylightTime under windows.

See attached cachegrind file.

See also:
http://pear.php.net/bugs/bug.php?id=434
http://pear.php.net/bugs/bug.php?id=6246

and the patch which introduced this is detailed in
http://pear.php.net/bugs/bug.php?id=1180

commenting out the putenv() calls prevents crashing but obviously produces incorrect results.

PEAR::Date should make sure that the TZ it is trying to insert is 'safe' - checking before writing to the registry

Test script:
---------------
 'Australia/Adelaide',
			 	2 	=> 'Australia/Canberra',
			 	3 	=> 'Australia/Darwin',
			 	4   => 'Australia/Brisbane',
			 	5 	=> 'Australia/Hobart',
			 	6   => 'Australia/Melbourne',
			 	7 	=> 'Australia/Perth',
			 	8 	=> 'Australia/Sydney'
);

$originalTimezone = new Date_TimeZone('Australia/Adelaide'); 

$n = 0;
while ($n < 10) {
	$new_date = new Date(time());
    print "old\n";
    print $new_date->getTime() . "\n";
	$timezone = new Date_TimeZone($states[$n++]); 
	$new_date->setTZ($originalTimezone);
	$new_date->convertTZ($timezone);

    print "new\n";
    print $new_date->getTime() . "\n";
}

Expected result:
----------------
old
(timestamp)
new
(timestamp)

... etc


Actual result:
--------------
version: 0.9.6
cmd: C:\vx\tests\pearDate.php
part: 1

events: Time

fl=php:internal
fn=php::getenv
4638 331

fl=php:internal
fn=php::getenv
4640 90

fl=php:internal
fn=php::date
4642 1058

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone::isValidID
4642 231

fl=php:internal
fn=php::date
4643 262

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone::isValidID
165 59

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone::setDefault
4643 898
cfn=Date_TimeZone::isValidID
calls=1 0 0
165 59

fl=c:\php\PEAR\Date\TimeZone.php
fn=require_once::c:\php\PEAR\Date\TimeZone.php
1 75187
cfn=php::getenv
calls=1 0 0
4638 331
cfn=php::getenv
calls=1 0 0
4640 90
cfn=php::date
calls=1 0 0
4642 1058
cfn=Date_TimeZone::isValidID
calls=1 0 0
4642 231
cfn=php::date
calls=1 0 0
4643 262
cfn=Date_TimeZone::setDefault
calls=1 0 0
4643 958

fl=php:internal
fn=php::defined
39 240

fl=php:internal
fn=php::define
46 81

fl=php:internal
fn=php::defined
49 90

fl=php:internal
fn=php::define
58 40

fl=c:\php\PEAR\Date\Calc.php
fn=require_once::c:\php\PEAR\Date\Calc.php
1 1456
cfn=php::defined
calls=1 0 0
39 240
cfn=php::define
calls=1 0 0
46 81
cfn=php::defined
calls=1 0 0
49 90
cfn=php::define
calls=1 0 0
58 40

fl=php:internal
fn=php::define
65 59

fl=c:\php\PEAR\Date\Span.php
fn=require_once::c:\php\PEAR\Date\Span.php
1 7779
cfn=php::define
calls=1 0 0
65 59

fl=php:internal
fn=php::define
50 40

fl=php:internal
fn=php::define
54 40

fl=php:internal
fn=php::define
58 40

fl=php:internal
fn=php::define
62 40

fl=php:internal
fn=php::define
66 50

fl=php:internal
fn=php::define
70 50

fl=c:\php\PEAR\Date.php
fn=require_once::c:\php\PEAR\Date.php
1 588028
cfn=require_once::c:\php\PEAR\Date\TimeZone.php
calls=1 0 0
39 78120
cfn=require_once::c:\php\PEAR\Date\Calc.php
calls=1 0 0
40 1909
cfn=require_once::c:\php\PEAR\Date\Span.php
calls=1 0 0
41 7839
cfn=php::define
calls=1 0 0
50 40
cfn=php::define
calls=1 0 0
54 40
cfn=php::define
calls=1 0 0
58 40
cfn=php::define
calls=1 0 0
62 40
cfn=php::define
calls=1 0 0
66 50
cfn=php::define
calls=1 0 0
70 50

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->isValidID
116 131

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->Date_TimeZone
14 886
cfn=Date_TimeZone->isValidID
calls=1 0 0
116 131

fl=php:internal
fn=php::time
18 19

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->isValidID
116 71

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->Date_TimeZone
151 457
cfn=Date_TimeZone->isValidID
calls=1 0 0
116 71

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->getDefault
155 460
cfn=Date_TimeZone->Date_TimeZone
calls=1 0 0
151 529

fl=php:internal
fn=php::is_null
156 59

fl=php:internal
fn=php::is_a
158 40

fl=php:internal
fn=php::preg_match
181 2369

fl=php:internal
fn=php::is_numeric
203 19

fl=php:internal
fn=php::date
205 557

fl=php:internal
fn=php::preg_match
181 269

fl=c:\php\PEAR\Date.php
fn=Date->setDate
205 789
cfn=php::preg_match
calls=1 0 0
181 269

fl=c:\php\PEAR\Date.php
fn=Date->setDate
161 1213
cfn=php::preg_match
calls=1 0 0
181 2369
cfn=php::is_numeric
calls=1 0 0
203 19
cfn=php::date
calls=1 0 0
205 557
cfn=Date->setDate
calls=1 0 0
205 1058

fl=c:\php\PEAR\Date.php
fn=Date->Date
18 1471
cfn=Date_TimeZone->getDefault
calls=1 0 0
155 989
cfn=php::is_null
calls=1 0 0
156 59
cfn=php::is_a
calls=1 0 0
158 40
cfn=Date->setDate
calls=1 0 0
161 5218

fl=php:internal
fn=php::mktime
259 407

fl=c:\php\PEAR\Date.php
fn=Date->getDate
471 522
cfn=php::mktime
calls=1 0 0
259 407

fl=c:\php\PEAR\Date.php
fn=Date->getTime
20 319
cfn=Date->getDate
calls=1 0 0
471 929

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->isValidID
116 69

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->Date_TimeZone
21 569
cfn=Date_TimeZone->isValidID
calls=1 0 0
116 69

fl=php:internal
fn=php::is_a
489 78

fl=c:\php\PEAR\Date.php
fn=Date->setTZ
22 321
cfn=php::is_a
calls=1 0 0
489 78

fl=php:internal
fn=php::getenv
263 100

fl=php:internal
fn=php::putenv
266 1010

fl=php:internal
fn=php::mktime
259 388

fl=c:\php\PEAR\Date.php
fn=Date->getDate
471 431
cfn=php::mktime
calls=1 0 0
259 388

fl=c:\php\PEAR\Date.php
fn=Date->getTime
267 338
cfn=Date->getDate
calls=1 0 0
471 820

fl=php:internal
fn=php::localtime
267 391

fl=php:internal
fn=php::putenv
268 770

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->inDaylightTime
305 3831
cfn=php::getenv
calls=1 0 0
263 100
cfn=php::putenv
calls=1 0 0
266 1010
cfn=Date->getTime
calls=1 0 0
267 1158
cfn=php::localtime
calls=1 0 0
267 391
cfn=php::putenv
calls=1 0 0
268 770

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->getOffset
563 576
cfn=Date_TimeZone->inDaylightTime
calls=1 0 0
305 7262

fl=php:internal
fn=php::getenv
263 78

fl=php:internal
fn=php::putenv
266 510

fl=php:internal
fn=php::mktime
259 698

fl=c:\php\PEAR\Date.php
fn=Date->getDate
471 591
cfn=php::mktime
calls=1 0 0
259 698

fl=c:\php\PEAR\Date.php
fn=Date->getTime
267 1108
cfn=Date->getDate
calls=1 0 0
471 1289

fl=php:internal
fn=php::localtime
267 269

fl=php:internal
fn=php::putenv
268 579

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->inDaylightTime
305 1273
cfn=php::X1
calls=1 0 0
263 78
cfn=php::putenv
calls=1 0 0
266 510
cfn=Date->getTime
calls=1 0 0
267 2398
cfn=php::localtime
calls=1 0 0
267 269
cfn=php::putenv
calls=1 0 0
268 579

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->getOffset
564 538
cfn=Date_TimeZone->inDaylightTime
calls=1 0 0
305 5109

fl=php:internal
fn=php::abs
564 78

fl=php:internal
fn=php::intval
564 21

fl=php:internal
fn=php::is_a
153 78

fl=php:internal
fn=php::is_a
155 30

fl=php:internal
fn=php::is_array
157 21

fl=php:internal
fn=php::is_string
159 11

fl=php:internal
fn=php::is_int
161 9

fl=php:internal
fn=php::intval
418 21

fl=php:internal
fn=php::floor
419 19

fl=php:internal
fn=php::floor
420 159

fl=php:internal
fn=php::floor
421 19

fl=php:internal
fn=php::intval
421 21

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->setFromSeconds
162 1931
cfn=php::intval
calls=1 0 0
418 21
cfn=php::floor
calls=1 0 0
419 19
cfn=php::floor
calls=1 0 0
420 159
cfn=php::floor
calls=1 0 0
421 19
cfn=php::intval
calls=1 0 0
421 21

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->set
129 2145
cfn=php::is_a
calls=1 0 0
153 78
cfn=php::is_a
calls=1 0 0
155 30
cfn=php::is_array
calls=1 0 0
157 21
cfn=php::is_string
calls=1 0 0
159 11
cfn=php::is_int
calls=1 0 0
161 9
cfn=Date_Span->setFromSeconds
calls=1 0 0
162 2171

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->Date_Span
699 498
cfn=Date_Span->set
calls=1 0 0
129 4470

fl=php:internal
fn=php::is_a
712 90

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->isEmpty
715 100

fl=php:internal
fn=php::substr
233 59

fl=php:internal
fn=php::substr
234 19

fl=php:internal
fn=php::floor
247 28

fl=php:internal
fn=php::floor
248 21

fl=php:internal
fn=php::floor
249 21

fl=c:\php\PEAR\Date\Calc.php
fn=Date_Calc->dateToDays
743 1468
cfn=php::substr
calls=1 0 0
233 59
cfn=php::substr
calls=1 0 0
234 19
cfn=php::floor
calls=1 0 0
247 28
cfn=php::floor
calls=1 0 0
248 21
cfn=php::floor
calls=1 0 0
249 21

fl=php:internal
fn=php::floor
267 9

fl=php:internal
fn=php::floor
268 19

fl=php:internal
fn=php::floor
269 19

fl=php:internal
fn=php::floor
271 19

fl=php:internal
fn=php::floor
272 21

fl=php:internal
fn=php::floor
273 19

fl=php:internal
fn=php::floor
275 21

fl=php:internal
fn=php::floor
276 9

fl=php:internal
fn=php::floor
277 19

fl=php:internal
fn=php::sprintf
289 159

fl=php:internal
fn=php::sprintf
290 40

fl=php:internal
fn=php::checkdate
1760 59

fl=c:\php\PEAR\Date\Calc.php
fn=Date_Calc->isValidDate
121 350
cfn=php::checkdate
calls=1 0 0
1760 59

fl=php:internal
fn=php::strlen
129 19

fl=php:internal
fn=php::substr
130 28

fl=php:internal
fn=php::substr
132 19

fl=php:internal
fn=php::strlen
129 21

fl=php:internal
fn=php::substr
130 21

fl=php:internal
fn=php::substr
132 9

fl=php:internal
fn=php::sprintf
159 38

fl=php:internal
fn=php::strlen
129 11

fl=php:internal
fn=php::substr
130 19

fl=php:internal
fn=php::substr
132 19

fl=php:internal
fn=php::sprintf
147 28

fl=php:internal
fn=php::strlen
129 9

fl=c:\php\PEAR\Date\Calc.php
fn=Date_Calc->dateFormat
291 5092
cfn=Date_Calc->isValidDate
calls=1 0 0
121 410
cfn=php::strlen
calls=1 0 0
129 19
cfn=php::substr
calls=1 0 0
130 28
cfn=php::substr
calls=1 0 0
132 19
cfn=php::strlen
calls=1 0 0
129 21
cfn=php::substr
calls=1 0 0
130 21
cfn=php::substr
calls=1 0 0
132 9
cfn=php::sprintf
calls=1 0 0
159 38
cfn=php::strlen
calls=1 0 0
129 11
cfn=php::substr
calls=1 0 0
130 19
cfn=php::substr
calls=1 0 0
132 19
cfn=php::sprintf
calls=1 0 0
147 28
cfn=php::strlen
calls=1 0 0
129 9

fl=c:\php\PEAR\Date\Calc.php
fn=Date_Calc->daysToDate
747 5204
cfn=php::floor
calls=1 0 0
267 9
cfn=php::floor
calls=1 0 0
268 19
cfn=php::floor
calls=1 0 0
269 19
cfn=php::floor
calls=1 0 0
271 19
cfn=php::floor
calls=1 0 0
272 21
cfn=php::floor
calls=1 0 0
273 19
cfn=php::floor
calls=1 0 0
275 21
cfn=php::floor
calls=1 0 0
276 9
cfn=php::floor
calls=1 0 0
277 19
cfn=php::sprintf
calls=1 0 0
289 159
cfn=php::sprintf
calls=1 0 0
290 40
cfn=Date_Calc->dateFormat
calls=1 0 0
291 5748

fl=php:internal
fn=php::sscanf
747 219

fl=php:internal
fn=php::intval
748 30

fl=php:internal
fn=php::intval
749 19

fl=php:internal
fn=php::intval
750 21

fl=c:\php\PEAR\Date.php
fn=Date->subtractSpan
699 3368
cfn=php::is_a
calls=1 0 0
712 90
cfn=Date_Span->isEmpty
calls=1 0 0
715 100
cfn=Date_Calc->dateToDays
calls=1 0 0
743 1618
cfn=Date_Calc->daysToDate
calls=1 0 0
747 11310
cfn=php::sscanf
calls=1 0 0
747 219
cfn=php::intval
calls=1 0 0
748 30
cfn=php::intval
calls=1 0 0
749 19
cfn=php::intval
calls=1 0 0
750 21

fl=c:\php\PEAR\Date.php
fn=Date->subtractSeconds
564 1020
cfn=Date_Span->Date_Span
calls=1 0 0
699 4968
cfn=Date->subtractSpan
calls=1 0 0
699 16779

fl=php:internal
fn=php::getenv
263 169

fl=php:internal
fn=php::putenv
266 669

fl=php:internal
fn=php::mktime
259 629

fl=c:\php\PEAR\Date.php
fn=Date->getDate
471 469
cfn=php::mktime
calls=1 0 0
259 629

fl=c:\php\PEAR\Date.php
fn=Date->getTime
267 331
cfn=Date->getDate
calls=1 0 0
471 1099

fl=php:internal
fn=php::localtime
267 300

fl=php:internal
fn=php::putenv
268 588

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->inDaylightTime
305 1330
cfn=php::getenv
calls=1 0 0
263 169
cfn=php::putenv
calls=1 0 0
266 669
cfn=Date->getTime
calls=1 0 0
267 1430
cfn=php::localtime
calls=1 0 0
267 300
cfn=php::putenv
calls=1 0 0
268 588

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->getOffset
569 519
cfn=Date_TimeZone->inDaylightTime
calls=1 0 0
305 4489

fl=php:internal
fn=php::getenv
263 78

fl=php:internal
fn=php::putenv
266 491

fl=php:internal
fn=php::mktime
259 751

fl=c:\php\PEAR\Date.php
fn=Date->getDate
471 469
cfn=php::mktime
calls=1 0 0
259 751

fl=c:\php\PEAR\Date.php
fn=Date->getTime
267 548
cfn=Date->getDate
calls=1 0 0
471 1220

fl=php:internal
fn=php::localtime
267 298

fl=php:internal
fn=php::putenv
268 579

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->inDaylightTime
305 1194
cfn=php::putenv
calls=1 0 0
263 78
cfn=php::putenv
calls=1 0 0
266 491
cfn=Date->getTime
calls=1 0 0
267 1769
cfn=php::localtime
calls=1 0 0
267 298
cfn=php::putenv
calls=1 0 0
268 579

fl=c:\php\PEAR\Date\TimeZone.php
fn=Date_TimeZone->getOffset
572 488
cfn=Date_TimeZone->inDaylightTime
calls=1 0 0
305 4410

fl=php:internal
fn=php::abs
572 19

fl=php:internal
fn=php::intval
572 21

fl=php:internal
fn=php::is_a
153 78

fl=php:internal
fn=php::is_a
155 40

fl=php:internal
fn=php::is_array
157 30

fl=php:internal
fn=php::is_string
159 9

fl=php:internal
fn=php::is_int
161 21

fl=php:internal
fn=php::intval
418 19

fl=php:internal
fn=php::floor
419 28

fl=php:internal
fn=php::floor
420 28

fl=php:internal
fn=php::floor
421 21

fl=php:internal
fn=php::intval
421 19

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->setFromSeconds
162 1752
cfn=php::intval
calls=1 0 0
418 19
cfn=php::floor
calls=1 0 0
419 28
cfn=php::floor
calls=1 0 0
420 28
cfn=php::floor
calls=1 0 0
421 21
cfn=php::intval
calls=1 0 0
421 19

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->set
129 2079
cfn=php::is_a
calls=1 0 0
153 78
cfn=php::is_a
calls=1 0 0
155 40
cfn=php::is_array
calls=1 0 0
157 30
cfn=php::is_string
calls=1 0 0
159 9
cfn=php::is_int
calls=1 0 0
161 21
cfn=Date_Span->setFromSeconds
calls=1 0 0
162 1869

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->Date_Span
699 472
cfn=Date_Span->set
calls=1 0 0
129 4129

fl=php:internal
fn=php::is_a
712 69

fl=c:\php\PEAR\Date\Span.php
fn=Date_Span->isEmpty
715 71

fl=c:\php\PEAR\Date.php
fn=Date->subtractSpan
699 538
cfn=php::is_a
calls=1 0 0
712 69
cfn=Date_Span->isEmpty
calls=1 0 0
715 71

fl=c:\php\PEAR\Date.php
fn=Ã¨Ã->subtractSeconds
572 898
cfn=Date_Span->Date_Span
calls=1 0 0
699 4601
cfn=Date->subtractSpan
calls=1 0 0
699 679

fl=c:\php\PEAR\Date.php
fn=Date->convertTZ
23 3404
cfn=Date_TimeZone->getOffset
calls=1 0 0
563 7839
cfn=Date_TimeZone->getOffset
calls=1 0 0
564 5648
cfn=php::Ã°Ã®TC
calls=1 0 0
564 78
cfn=php::intval
calls=1 0 0
564 21
cfn=Date->subtractSeconds
calls=1 0 0
564 22768
cfn=Date_TimeZone->getOffset
calls=1 0 0
569 5009
cfn=Date_TimeZone->getOffset
calls=1 0 0
572 4899
cfn=php::abs
calls=1 0 0
572 19
cfn=php::intval
calls=1 0 0
572 21
cfn=Ã¨Ã->subtractSeconds
calls=1 0 0
572 6179

Date: Bug 2378 [Open] getDate(DATE_FORMAT_UNIXTIME) doesn't convert to GMT

scragz at hotmail dot com — 2009-01-01T08:53:14+00:00

Date Bug
Reported by scragz@...
2004-09-23T10:32:24+00:00
PHP: 4.3.8 OS: Debian Sarge Package Version: 

Description:
------------
If you have a Date in another TZ and ask use getDate(DATE_FORMAT_UNIXTIME) or getTime() the timestamp returned will be wrong since it is only using mktime.

Trying to fix this caused me some problems, but I have a patch (below) that seems to work.

Reproduce code:
---------------
getTime()."\n";
$date->convertTZbyID('America/Los_Angeles');
echo $date->getTime()."\n";
?>

This patch corrects the faulty behavior. I'm not sure if DATE_FORMAT_TIMESTAMP is expected to be GMT, but this could be adapted to that as well.

Index: Date.php
===================================================================
--- Date.php    (revision 111)
+++ Date.php    (working copy)
@@ -231,7 +231,16 @@
             return $this->format("%Y%m%d%H%M%S");
             break;
         case DATE_FORMAT_UNIXTIME:
-            return mktime($this->hour, $this->minute, $this->second, $this->month, $this->day, $this->year);
+            $date =& new Date($this);
+            if ($date->tz->offset) {
+                $offset = ($date->tz->offset + $date->tz->getDSTSavings()) / 1000;
+                if ($offset > 0) {
+                    $date->subtractSeconds(intval($offset));
+                } else {
+                    $date->addSeconds(intval(abs($offset)));
+                }
+            }
+            return mktime($date->hour, $date->minute, $date->second, $date->month, $date->day, $date->year);
             break;
         }
     }

Expected result:
----------------
1095935549
1095935549

Actual result:
--------------
1095935549
1095910349