#45554 [Com]: Inconsistent behavior of the u format char
ID: 45554
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X
PHP Version: 5.3CVS-2008-07-18 (CVS)
New Comment:
It seems that I am not totally awake.
So date_create_from_format('m-d-Y H:i:s T', $dateTime->format('m-d-Y
H:i:s T')); will generate an error.
should read:
So date_create_from_format('m-d-Y H:i:s.u T', $dateTime->format('m-d-Y
H:i:s.u T')); will generate an error.
Previous Comments:
----------------
[2008-07-18 11:28:52] tj at systisoft dot com
Upsi, there should be 6 zeros in the microsecond part of the expected
result.
----------------
[2008-07-18 11:26:24] tj at systisoft dot com
Description:
The u format char behaves inconsistent.
1. In output the it uses 6 digits. When used in date_create_from_format
it recognizes only up to 5 digits (though microseconds would be 6). So
date_create_from_format('m-d-Y H:i:s T', $dateTime->format('m-d-Y H:i:s
T')); will generate an error.
2. Though DateTime does not support microseconds (or does it?) and
should cut them off it behaves very strange when parsing a date with
fractional seconds.
Reproduce code:
---
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005
12:22:29.0 PST");
echo $d->format("m-d-Y H:i:s.u T");
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005
12:22:29.00100 PST");
echo $d->format("m-d-Y H:i:s.u T");
Expected result:
03-15-2005 12:22:29.0 PST
03-15-2005 12:22:29.0 PST
Actual result:
--
03-15-2005 12:22:29.00 PST
03-15-2005 12:22:29.1 PST
--
Edit this bug report at http://bugs.php.net/?id=45554&edit=1
#45554 [Com]: Inconsistent behavior of the u format char
ID: 45554
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X
PHP Version: 5.3CVS-2008-07-18 (CVS)
New Comment:
Upsi, there should be 6 zeros in the microsecond part of the expected
result.
Previous Comments:
[2008-07-18 11:26:24] tj at systisoft dot com
Description:
The u format char behaves inconsistent.
1. In output the it uses 6 digits. When used in date_create_from_format
it recognizes only up to 5 digits (though microseconds would be 6). So
date_create_from_format('m-d-Y H:i:s T', $dateTime->format('m-d-Y H:i:s
T')); will generate an error.
2. Though DateTime does not support microseconds (or does it?) and
should cut them off it behaves very strange when parsing a date with
fractional seconds.
Reproduce code:
---
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005
12:22:29.0 PST");
echo $d->format("m-d-Y H:i:s.u T");
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005
12:22:29.00100 PST");
echo $d->format("m-d-Y H:i:s.u T");
Expected result:
03-15-2005 12:22:29.0 PST
03-15-2005 12:22:29.0 PST
Actual result:
--
03-15-2005 12:22:29.00 PST
03-15-2005 12:22:29.1 PST
--
Edit this bug report at http://bugs.php.net/?id=45554&edit=1
#45554 [NEW]: Inconsistent behavior of the u format char
From: tj at systisoft dot com
Operating system: Mac OS X
PHP version: 5.3CVS-2008-07-18 (CVS)
PHP Bug Type: Date/time related
Bug description: Inconsistent behavior of the u format char
Description:
The u format char behaves inconsistent.
1. In output the it uses 6 digits. When used in date_create_from_format it
recognizes only up to 5 digits (though microseconds would be 6). So
date_create_from_format('m-d-Y H:i:s T', $dateTime->format('m-d-Y H:i:s
T')); will generate an error.
2. Though DateTime does not support microseconds (or does it?) and should
cut them off it behaves very strange when parsing a date with fractional
seconds.
Reproduce code:
---
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005 12:22:29.0
PST");
echo $d->format("m-d-Y H:i:s.u T");
$d = date_create_from_format("m-d-Y H:i:s.u T", "03-15-2005 12:22:29.00100
PST");
echo $d->format("m-d-Y H:i:s.u T");
Expected result:
03-15-2005 12:22:29.0 PST
03-15-2005 12:22:29.0 PST
Actual result:
--
03-15-2005 12:22:29.00 PST
03-15-2005 12:22:29.1 PST
--
Edit bug report at http://bugs.php.net/?id=45554&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45554&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45554&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45554&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45554&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45554&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45554&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45554&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45554&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45554&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45554&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45554&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45554&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45554&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45554&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45554&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45554&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45554&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45554&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45554&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45554&r=mysqlcfg
#45545 [Com]: DateInterval has a limitation of 4 chars for ISO durations
ID: 45545
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
Assigned To: derick
New Comment:
Also
php -r '$d = new DateTime("2005-03-15 12:22:29-"); $d->add("36000
seconds"); var_dump($d->format(DATE_ISO8601));'
gives to me:
PHP Warning: DateTime::add() expects parameter 1 to be DateInterval,
string given in Command line code on line 1
Warning: DateTime::add() expects parameter 1 to be DateInterval, string
given in Command line code on line 1
So I don't think this is a solution for now.
Previous Comments:
------------
[2008-07-18 09:07:28] tj at systisoft dot com
Ok, that is a solution.
Since I am somewhat new to PHP all this numbers to strings stuff is a
bit disquietingly for me :).
[2008-07-18 08:30:03] [EMAIL PROTECTED]
You can also just do:
$dateTime->add("718231 seconds");
--------------------
[2008-07-18 08:19:47] tj at systisoft dot com
I forgot: At least max int would be nice as limit because then
everywhere you get a duration as int you don't have to care about the
limit of the DateInterval constructor.
----------------
[2008-07-18 08:16:43] tj at systisoft dot com
Just an example when whis is awkward:
I get an offest from a time zone an have to add it to a DateTime. The
offset was taken from the time zone via getOffset(). Lets assume the
offset is positive (easy test if not).
$d->add(new DateInterval('PT' . $offset . 'S')));
will fail once the offset is over seconds.
While it is not really necessary to have the limit removed, it is just
awkward for a user that he always has to care about this limit when
handling durations he gets from sources he can not control. There will
always be a limit you have to take care of but a limit of seconds
is reached very fast, if you get durations in seconds.
[2008-07-17 17:22:42] [EMAIL PROTECTED]
I don't think the limit is really needed - but then again, I also don't
think it matters much that you can't have periods of > 1000seconds.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45545
--
Edit this bug report at http://bugs.php.net/?id=45545&edit=1
#45545 [Com]: DateInterval has a limitation of 4 chars for ISO durations
ID: 45545
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
Assigned To: derick
New Comment:
Ok, that is a solution.
Since I am somewhat new to PHP all this numbers to strings stuff is a
bit disquietingly for me :).
Previous Comments:
[2008-07-18 08:30:03] [EMAIL PROTECTED]
You can also just do:
$dateTime->add("718231 seconds");
[2008-07-18 08:19:47] tj at systisoft dot com
I forgot: At least max int would be nice as limit because then
everywhere you get a duration as int you don't have to care about the
limit of the DateInterval constructor.
[2008-07-18 08:16:43] tj at systisoft dot com
Just an example when whis is awkward:
I get an offest from a time zone an have to add it to a DateTime. The
offset was taken from the time zone via getOffset(). Lets assume the
offset is positive (easy test if not).
$d->add(new DateInterval('PT' . $offset . 'S')));
will fail once the offset is over seconds.
While it is not really necessary to have the limit removed, it is just
awkward for a user that he always has to care about this limit when
handling durations he gets from sources he can not control. There will
always be a limit you have to take care of but a limit of seconds
is reached very fast, if you get durations in seconds.
[2008-07-17 17:22:42] [EMAIL PROTECTED]
I don't think the limit is really needed - but then again, I also don't
think it matters much that you can't have periods of > 1000seconds.
----------------
[2008-07-17 16:24:50] tj at systisoft dot com
If you decide to keep the limit you should move that to documentation I
think :).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45545
--
Edit this bug report at http://bugs.php.net/?id=45545&edit=1
#45545 [Com]: DateInterval has a limitation of 4 chars for ISO durations
ID: 45545
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
Assigned To: derick
New Comment:
I forgot: At least max int would be nice as limit because then
everywhere you get a duration as int you don't have to care about the
limit of the DateInterval constructor.
Previous Comments:
[2008-07-18 08:16:43] tj at systisoft dot com
Just an example when whis is awkward:
I get an offest from a time zone an have to add it to a DateTime. The
offset was taken from the time zone via getOffset(). Lets assume the
offset is positive (easy test if not).
$d->add(new DateInterval('PT' . $offset . 'S')));
will fail once the offset is over seconds.
While it is not really necessary to have the limit removed, it is just
awkward for a user that he always has to care about this limit when
handling durations he gets from sources he can not control. There will
always be a limit you have to take care of but a limit of seconds
is reached very fast, if you get durations in seconds.
[2008-07-17 17:22:42] [EMAIL PROTECTED]
I don't think the limit is really needed - but then again, I also don't
think it matters much that you can't have periods of > 1000seconds.
----------------
[2008-07-17 16:24:50] tj at systisoft dot com
If you decide to keep the limit you should move that to documentation I
think :).
----------------
[2008-07-17 16:17:58] tj at systisoft dot com
Description:
If you want to create a DateInterval of 36000 seconds (10 hours) the
creation will fail because you have a limit of 4 chars in the format
accepted by the constructor.
Up to days you can do the "carry over" calculation for yourself (But
not for months or years), but if you get an offset in seconds from a
source you cannot control it would be nice if you could just do:
$date->add(new DateInterval('PT' . $seconds . 'S'));
Now you have to check if seconds exceeds the limit an if it exceeds the
limit you have to recalculate yourself. That is not nice from a user
point of view.
Reproduce code:
---
$d = new DateTime('2008-01-01 10:00:00 UTC');
$d->add(new DateInterval('PT36000S'));
echo $d->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T20:00:00+
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=45545&edit=1
#45545 [Com]: DateInterval has a limitation of 4 chars for ISO durations
ID: 45545
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
Assigned To: derick
New Comment:
Just an example when whis is awkward:
I get an offest from a time zone an have to add it to a DateTime. The
offset was taken from the time zone via getOffset(). Lets assume the
offset is positive (easy test if not).
$d->add(new DateInterval('PT' . $offset . 'S')));
will fail once the offset is over seconds.
While it is not really necessary to have the limit removed, it is just
awkward for a user that he always has to care about this limit when
handling durations he gets from sources he can not control. There will
always be a limit you have to take care of but a limit of seconds
is reached very fast, if you get durations in seconds.
Previous Comments:
[2008-07-17 17:22:42] [EMAIL PROTECTED]
I don't think the limit is really needed - but then again, I also don't
think it matters much that you can't have periods of > 1000seconds.
------------
[2008-07-17 16:24:50] tj at systisoft dot com
If you decide to keep the limit you should move that to documentation I
think :).
------------
[2008-07-17 16:17:58] tj at systisoft dot com
Description:
If you want to create a DateInterval of 36000 seconds (10 hours) the
creation will fail because you have a limit of 4 chars in the format
accepted by the constructor.
Up to days you can do the "carry over" calculation for yourself (But
not for months or years), but if you get an offset in seconds from a
source you cannot control it would be nice if you could just do:
$date->add(new DateInterval('PT' . $seconds . 'S'));
Now you have to check if seconds exceeds the limit an if it exceeds the
limit you have to recalculate yourself. That is not nice from a user
point of view.
Reproduce code:
---
$d = new DateTime('2008-01-01 10:00:00 UTC');
$d->add(new DateInterval('PT36000S'));
echo $d->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T20:00:00+
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=45545&edit=1
#45545 [Com]: DateInterval has a limitation of 4 chars for ISO durations
ID: 45545
Comment by: tj at systisoft dot com
Reported By: tj at systisoft dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
New Comment:
If you decide to keep the limit you should move that to documentation I
think :).
Previous Comments:
[2008-07-17 16:17:58] tj at systisoft dot com
Description:
If you want to create a DateInterval of 36000 seconds (10 hours) the
creation will fail because you have a limit of 4 chars in the format
accepted by the constructor.
Up to days you can do the "carry over" calculation for yourself (But
not for months or years), but if you get an offset in seconds from a
source you cannot control it would be nice if you could just do:
$date->add(new DateInterval('PT' . $seconds . 'S'));
Now you have to check if seconds exceeds the limit an if it exceeds the
limit you have to recalculate yourself. That is not nice from a user
point of view.
Reproduce code:
---
$d = new DateTime('2008-01-01 10:00:00 UTC');
$d->add(new DateInterval('PT36000S'));
echo $d->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T20:00:00+
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=45545&edit=1
#45545 [NEW]: DateInterval has a limitation of 4 chars for ISO durations
From: tj at systisoft dot com
Operating system: All
PHP version: 5.3CVS-2008-07-17 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: DateInterval has a limitation of 4 chars for ISO durations
Description:
If you want to create a DateInterval of 36000 seconds (10 hours) the
creation will fail because you have a limit of 4 chars in the format
accepted by the constructor.
Up to days you can do the "carry over" calculation for yourself (But not
for months or years), but if you get an offset in seconds from a source you
cannot control it would be nice if you could just do:
$date->add(new DateInterval('PT' . $seconds . 'S'));
Now you have to check if seconds exceeds the limit an if it exceeds the
limit you have to recalculate yourself. That is not nice from a user point
of view.
Reproduce code:
---
$d = new DateTime('2008-01-01 10:00:00 UTC');
$d->add(new DateInterval('PT36000S'));
echo $d->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T20:00:00+
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT36000S)' in
/Users/tobias/test.php:2
Stack trace:
#0 /Users/tobias/test.php(2): DateInterval->__construct('PT36000S')
#1 {main}
thrown in /Users/tobias/test.php on line 2
--
Edit bug report at http://bugs.php.net/?id=45545&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45545&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45545&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45545&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45545&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45545&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45545&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45545&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45545&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45545&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45545&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45545&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45545&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45545&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45545&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45545&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45545&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45545&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45545&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45545&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45545&r=mysqlcfg
#45543 [Opn]: DateTime::setTimezone can not set timezones without ID
ID: 45543
User updated by: tj at systisoft dot com
-Summary: DateTime::setTimezone kann not set timezones without
ID
Reported By: tj at systisoft dot com
Status: Open
-Bug Type: Date/time related
+Bug Type: Feature/Change Request
-Operating System: Mac OS X
+Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
New Comment:
Description:
If you set a time zone for a DateTime via DateTime::setTimeZone() and
that time zone has no ID you get an error message and the time zone will
not be set.
This can lead to problems if you have two DateTime objects from a
source you do not control and want to format the second DateTime object
in the same time zone as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID
for
now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
Previous Comments:
--------
[2008-07-17 13:07:47] tj at systisoft dot com
Description:
if you set a time zone for a DateTime via DateTime::setTimeZone() and
that time zone has no ID you get an error message and the time zone will
not be set.
This can lead to Problems if you have two DateTime objects from a surce
you do not control and want to format the secont DateTime object in the
same time zone as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID
for now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
--
Edit this bug report at http://bugs.php.net/?id=45543&edit=1
#45543 [NEW]: DateTime::setTimezone kann not set timezones without ID
From: tj at systisoft dot com
Operating system: Mac OS X
PHP version: 5.3CVS-2008-07-17 (CVS)
PHP Bug Type: Date/time related
Bug description: DateTime::setTimezone kann not set timezones without ID
Description:
if you set a time zone for a DateTime via DateTime::setTimeZone() and that
time zone has no ID you get an error message and the time zone will not be
set.
This can lead to Problems if you have two DateTime objects from a surce
you do not control and want to format the secont DateTime object in the
same time zone as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with ID
for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID for
now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
--
Edit bug report at http://bugs.php.net/?id=45543&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45543&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45543&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45543&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45543&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45543&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45543&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45543&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45543&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45543&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45543&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45543&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45543&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45543&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45543&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45543&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45543&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45543&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45543&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45543&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45543&r=mysqlcfg
#45483 [Com]: Add an era designater to DateTime methods when formatting or parsing dates
ID: 45483 Comment by: tj at systisoft dot com Reported By: tj at systisoft dot com Status: Assigned Bug Type: Feature/Change Request Operating System: All PHP Version: 5.3CVS-2008-07-11 (CVS) Assigned To: derick New Comment: On further thinking there should be a new format char for BC dates because Y formats the date with year 0 which is conforming with ISO8601. But years in the proleptic Gregorian calendar do not have a year 0. The year 0 in ISO8601 is 1 BC in the proleptic Gregorian calendar. Previous Comments: [2008-07-15 11:47:34] tj at systisoft dot com There should also be a possibility to format a year without the sign, because if you format with 'Y' you will get something like: -2000 BC This can either be done by an new format char for unsigned year or that the 'Y' format is omitting the sign when a format char for the era designator is present. [2008-07-11 10:18:11] tj at systisoft dot com Description: It is currently not possible to specify an era designator in a format when parsing or formatting dates with DateTime::createFromFormat or DateTime::format. An era designater would be BC or AD as in 1/1/0200 BC or 1/1/2004 AD. I don't know which format char would be good since 'G' which is used in some other format patterns as era designator seems to be already taken. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=45483&edit=1
#45529 [NEW]: new DateTimeZone() and date_create()->getTimezone() behave diffent
From: tj at systisoft dot com
Operating system: Mac OS X
PHP version: 5.3CVS-2008-07-16 (CVS)
PHP Bug Type: Date/time related
Bug description: new DateTimeZone() and date_create()->getTimezone() behave
diffent
Description:
If you generate a DateTimeZone with new and one with
date_create()->getTimeZone, the resulting DateTimeZone objects behave
different even if the are of the same time zone.
Reproduce code:
---
$tz1 = new DateTimeZone('UTC');
$tz2 = date_create('UTC')->getTimeZone();
echo $tz1->getName(), PHP_EOL;
echo $tz2->getName(), PHP_EOL;
$d = new DateTime('2008-01-01 12:00:00+0200');
$d->setTimeZone($tz1);
echo $d->format(DATE_ISO8601), PHP_EOL;
$d = new DateTime('2008-01-01 12:00:00+0200');
$d->setTimeZone($tz2);
echo $d->format(DATE_ISO8601), PHP_EOL;
Expected result:
UTC
UTC
2008-1-1T10:00:00+
2008-1-1T10:00:00+
Actual result:
--
UTC
UTC
2008-01-01T10:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with ID
for now in /Users/tobias/test.php on line 9
Warning: DateTime::setTimezone(): Can only do this for zones with ID for
now in /Users/tobias/test.php on line 9
2008-01-01T12:00:00+0200
--
Edit bug report at http://bugs.php.net/?id=45529&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45529&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45529&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45529&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45529&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45529&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45529&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45529&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45529&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45529&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45529&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45529&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45529&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45529&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45529&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45529&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45529&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45529&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45529&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45529&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45529&r=mysqlcfg
#45528 [NEW]: You cannot initialize a DateTimeZone object by offset only.
From: tj at systisoft dot com
Operating system: All
PHP version: 5.3CVS-2008-07-16 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: You cannot initialize a DateTimeZone object by offset only.
Description:
Sometimes you get timezones from other sources in offset only format. This
is often the case when dealing with databases.
So yo have sometimes the situation where you have to set a time zone to a
DateTime that is only defined by the offset. While an offset alone is not a
time zone the DateTimeZone object can handle them by treating them as a
time zone without daylight saving and offset, the name of that time zone is
the offset itself. This seems to be the way if such time zones are obtained
from a DateTime object.
It would be nice behavior if new DateTimeZone($d->getName()) will always
succeed if $d is a DateTimeZone.
Reproduce code:
---
$d = new DateTimeZone(date_create('+01:00')->getTimeZone()->getName());
echo $d->getName();
Expected result:
+01:00
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateTimeZone::__construct(): Unknown or bad timezone (+01:00)' in Command
line code:1
--
Edit bug report at http://bugs.php.net/?id=45528&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45528&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45528&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45528&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45528&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45528&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45528&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45528&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45528&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45528&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45528&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45528&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45528&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45528&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45528&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45528&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45528&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45528&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45528&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45528&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45528&r=mysqlcfg
#45483 [Com]: Add an era designater to DateTime methods when formatting or parsing dates
ID: 45483 Comment by: tj at systisoft dot com Reported By: tj at systisoft dot com Status: Assigned Bug Type: Feature/Change Request Operating System: All PHP Version: 5.3CVS-2008-07-11 (CVS) Assigned To: derick New Comment: There should also be a possibility to format a year without the sign, because if you format with 'Y' you will get something like: -2000 BC This can either be done by an new format char for unsigned year or that the 'Y' format is omitting the sign when a format char for the era designator is present. Previous Comments: [2008-07-11 10:18:11] tj at systisoft dot com Description: It is currently not possible to specify an era designator in a format when parsing or formatting dates with DateTime::createFromFormat or DateTime::format. An era designater would be BC or AD as in 1/1/0200 BC or 1/1/2004 AD. I don't know which format char would be good since 'G' which is used in some other format patterns as era designator seems to be already taken. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=45483&edit=1
#45509 [NEW]: create_date_from_format cannot parse negative (BC) dates
From: tj at systisoft dot com
Operating system: Mac OS X
PHP version: 5.3CVS-2008-07-14 (CVS)
PHP Bug Type: Date/time related
Bug description: create_date_from_format cannot parse negative (BC) dates
Description:
While the constructor of DateTime can handle negaive dates (BC dates),
create_date_from_format cannot.
Reproduce code:
---
$d = new DateTime("-4000-01-31"); echo $d->format("Y-m-d"), PHP_EOL;
$d = date_create_from_format("Y-m-d", "4000-01-31"); echo
$d->format("Y-m-d"), PHP_EOL;
$d = date_create_from_format("Y-m-d", "-4000-01-31"); echo
$d->format("Y-m-d"), PHP_EOL;
Expected result:
-4000-01-31
4000-01-31
-4000-01-31
Actual result:
--
-4000-01-31
4000-01-31
PHP Fatal error: Call to a member function format() on a non-object in
Command line code on line 3
--
Edit bug report at http://bugs.php.net/?id=45509&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45509&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45509&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45509&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45509&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45509&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45509&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45509&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45509&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45509&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45509&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45509&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45509&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45509&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45509&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45509&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45509&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45509&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45509&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45509&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45509&r=mysqlcfg
#45483 [NEW]: Add an era designater to DateTime methods when formatting or parsing dates
From: tj at systisoft dot com Operating system: All PHP version: 5.3CVS-2008-07-11 (CVS) PHP Bug Type: Feature/Change Request Bug description: Add an era designater to DateTime methods when formatting or parsing dates Description: It is currently not possible to specify an era designator in a format when parsing or formatting dates with DateTime::createFromFormat or DateTime::format. An era designater would be BC or AD as in 1/1/0200 BC or 1/1/2004 AD. I don't know which format char would be good since 'G' which is used in some other format patterns as era designator seems to be already taken. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit bug report at http://bugs.php.net/?id=45483&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45483&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45483&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45483&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45483&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45483&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45483&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45483&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45483&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45483&r=support Expected behavior:http://bugs.php.net/fix.php?id=45483&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45483&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45483&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45483&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45483&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45483&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45483&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45483&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45483&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45483&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45483&r=mysqlcfg
