Description:
------------
After upgrading to 5.3.0 RC2, date('Y') always returns 0000. No php.ini
setting (date.timezone) seems to have any influence.

date('y') works as expected and returns 09.

This Problem did not occur with 5.3.0RC1.

Reproduce code:
---------------
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 
<?=date('Y') ?>
0000

Expected result:
----------------
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 
<?=date('Y') ?>
2009

Actual result:
--------------
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 
<?=date('Y') ?>
0000

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

Bleh, wrong link. Anyway, I can not reproduce this on Linux.

Me neither, I have 5.3.0RC2 flawlessly working on Linux, 
The issue occurs on my development system on Mac OS X 10.4 PPC only with

5.3.0RC2. RC1 works correct. Strange, I know.

Could you provide access? I don't have the possibility to test and debug
on this specific platform myself.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

DateTime is also affected:

$oDateTime = new DateTime();
    
print_r($oDateTime);

Result:
DateTime Object
(
    [date] => 0000-05-24 21:27:10
    [timezone_type] => 3
    [timezone] => Europe/Berlin
)

I still can't reproduce this, and I still don't have access to this
platform.

I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2.

$oDateTime = new DateTime();
print_r($oDateTime);

Result:
DateTime Object
(
    [date] => 2009-05-27 14:57:33
    [timezone_type] => 3
    [timezone] => America/Phoenix
)

echo date('y');
Result:
09

echo date('Y');
Result:
2009

PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same 
results.

I just verified the issue unter Linux PPC, Debian Lenny PPC to be 
specific.

So there is an endian issue somewhere.  How are you with gdb?  Could you
set a breakpoint on the function and work your way through it and figure
out where it goes south?

We have a PPC test machine, Derick has access and I can set up other
accounts if needed.

Oh, I had forgotten about that PPC machine. I'll have a look.

Seems like it's an issue in slprintf:

1017			switch (format[i]) {
(gdb) 
1043					timelib_sll year = PHP_LLABS(t->y);
(gdb) print year
$1 = 1230768000
(gdb) next
1044					length = slprintf(buffer, 32, "%s%04ld", t->y < 0 ? "-" : "",
year); break;
(gdb) print year
$2 = 2009
(gdb) next
1124			smart_str_appendl(&string, buffer, length);
(gdb) print buffer
$3 =
"0000\000\000\004\202\000\000\000\000\000\000\000\000I\\\a\200\000\000\0
00\000\000\000\0006\000\000\000\000"
(gdb) next
1015		for (i = 0; i < format_len; i++) {
(gdb) print &string
$4 = (smart_str *) 0xffa1cde0
(gdb) print string
$5 = {c = 0x1071f060 "0000\020q�X\020c\003�", len = 4, a = 78}

This bug still exits in the same way with PHP 5.2.10.

Found after upgrade from 5.2.9 to 5.2.10 on a Mac OS X 10.4.11 Server 
PPC.

With 5.2.9 

     <?=date(Y); ?>

works as expected.

Also, seeing this after upgrading from 5.2.9 to 5.2.10.

On Solaris Sparc version 9.

     <?=date(Y); ?>

returns 0000 on 5.2.10
and returns 2009 as expected on 5.2.9

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

The year was a long long, but we were printing it like a long. Since
sparc and ppc are big endian it was grabbing the wrong bits so to speak
:)