[PHP-BUG] Bug #65729 [NEW]: CN_match gives false positive
From: datibbaw Operating system: Linux PHP version: master-Git-2013-09-21 (Git) Package: OpenSSL related Bug Type: Bug Bug description:CN_match gives false positive Description: When the CN_match option is used to verify "foo.test.com.sg" and the server certificate CN is "*.test.com" it will succeed erroneously. Test script: --- $context = stream_context_create(['ssl' => [ 'verify_peer' => true, 'allow_self_signed' => true, 'CN_match' => 'foo.test.com.sg', ]]); $s = file_get_contents($url, 'rt', $context); var_dump($s); Expected result: Warning: file_get_contents(): Peer certificate CN=`*.test.com' did not match expected CN=`foo.test.com.sg' in /path/to/script.php on line 12 Warning: file_get_contents(): Failed to enable crypto in /Users/tjerk/work/ssl/ssl.php on line 11 Warning: file_get_contents(https://localhost:4433): failed to open stream: operation failed in /path/to/script.php on line 11 bool(false) Actual result: -- No errors. -- Edit bug report at https://bugs.php.net/bug.php?id=65729&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65729&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65729&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65729&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65729&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65729&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65729&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65729&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65729&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65729&r=support Expected behavior: https://bugs.php.net/fix.php?id=65729&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65729&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65729&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65729&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65729&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65729&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65729&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65729&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65729&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65729&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65729&r=mysqlcfg
[PHP-BUG] Bug #65730 [NEW]: DateTime::format('W') returns wrong week number
From: glavic at gmail dot com
Operating system: ALL
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::format('W') returns wrong week number
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit bug report at https://bugs.php.net/bug.php?id=65730&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65730&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65730&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65730&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65730&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65730&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65730&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65730&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65730&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65730&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65730&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65730&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65730&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65730&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65730&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65730&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65730&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65730&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65730&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65730&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65730&r=mysqlcfg
Bug #65730 [Opn->Nab]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Updated by: ras...@php.net
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
Previous Comments:
[2013-09-21 11:04:29] glavic at gmail dot com
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #65730 [Com]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Comment by: glavic at gmail dot com
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@rasmus: I never said nothing about first or last week of the month containing
dates from before/after year. You probably agree with statement that the last
week of the year 2013 (and first week of the year 2014) is from 2013-12-30 to
2014-01-05?
I reported this, not because what you said, but because code "echo (new
DateTime('2013-12-30'))->format('Y W');" returns "2013 01" which is incorrect,
and for me this is bug. This should, like I already said in report, return
"2014 01".
Code "echo (new DateTime('2012-12-31'))->format('Y W');" also returns "2013
01". So now we have two identical week number for year 2013 with a year
difference between dates ;)
Previous Comments:
[2013-09-21 14:33:53] ras...@php.net
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
[2013-09-21 11:04:29] glavic at gmail dot com
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #65730 [Nab]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Updated by: ras...@php.net
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
2013-12-30 ('Y W');" returns "2013 01" is correct. The 'Y' is the year. The ISO
8601 Year for 2013-12-30 is obviously 2013. However the ISO 8601 Week number
for
2013-12-30 is also just as obviously 1. So 2013 01 is correct.
And your next statement makes no sense either:
"So now we have two identical week number for year 2013 with a year difference
between dates ;)"
We are talking about Dec.30 and 31 in 2013. That is Monday and Tuesday. They
both fall in ISO week 1 and they are both in 2013. Wednesday Jan.1 2014 also
falls in ISO week 1 even though it is in 2014. That's how ISO weeks work.
Is your confusion that you think the 'Y' has to be associated with the 'W'
somehow? The 'Y' refers to the date you are formatting.
Previous Comments:
[2013-09-21 18:05:44] glavic at gmail dot com
@rasmus: I never said nothing about first or last week of the month containing
dates from before/after year. You probably agree with statement that the last
week of the year 2013 (and first week of the year 2014) is from 2013-12-30 to
2014-01-05?
I reported this, not because what you said, but because code "echo (new
DateTime('2013-12-30'))->format('Y W');" returns "2013 01" which is incorrect,
and for me this is bug. This should, like I already said in report, return
"2014 01".
Code "echo (new DateTime('2012-12-31'))->format('Y W');" also returns "2013
01". So now we have two identical week number for year 2013 with a year
difference between dates ;)
[2013-09-21 14:33:53] ras...@php.net
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
[2013-09-21 11:04:29] glavic at gmail dot com
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #65730 [Com]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Comment by: glavic at gmail dot com
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I made a copy/paste typo before, but that doesn't matter now because you said
that 'Y' returns the year of the date, which is totally correct, where was my
head...
I understand what you are saying; I agree that Dec 30 and 31 fall in week 1;
but year 2014, not 2013.
Maybe I should rephrase my question: how do I get correct week year from "echo
(new DateTime('2013-12-30'))->format('W ');" ?
Previous Comments:
[2013-09-21 18:18:50] ras...@php.net
2013-12-30 ('Y W');" returns "2013 01" is correct. The 'Y' is the year. The ISO
8601 Year for 2013-12-30 is obviously 2013. However the ISO 8601 Week number
for
2013-12-30 is also just as obviously 1. So 2013 01 is correct.
And your next statement makes no sense either:
"So now we have two identical week number for year 2013 with a year difference
between dates ;)"
We are talking about Dec.30 and 31 in 2013. That is Monday and Tuesday. They
both fall in ISO week 1 and they are both in 2013. Wednesday Jan.1 2014 also
falls in ISO week 1 even though it is in 2014. That's how ISO weeks work.
Is your confusion that you think the 'Y' has to be associated with the 'W'
somehow? The 'Y' refers to the date you are formatting.
[2013-09-21 18:05:44] glavic at gmail dot com
@rasmus: I never said nothing about first or last week of the month containing
dates from before/after year. You probably agree with statement that the last
week of the year 2013 (and first week of the year 2014) is from 2013-12-30 to
2014-01-05?
I reported this, not because what you said, but because code "echo (new
DateTime('2013-12-30'))->format('Y W');" returns "2013 01" which is incorrect,
and for me this is bug. This should, like I already said in report, return
"2014 01".
Code "echo (new DateTime('2012-12-31'))->format('Y W');" also returns "2013
01". So now we have two identical week number for year 2013 with a year
difference between dates ;)
[2013-09-21 14:33:53] ras...@php.net
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
[2013-09-21 11:04:29] glavic at gmail dot com
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #65730 [Com]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Comment by: glavic at gmail dot com
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Ah, I found it, it is 'o' format character.
Sorry for your trouble. Can you delete this failed bug report? ;)
Tnx
Previous Comments:
[2013-09-21 18:48:10] glavic at gmail dot com
I made a copy/paste typo before, but that doesn't matter now because you said
that 'Y' returns the year of the date, which is totally correct, where was my
head...
I understand what you are saying; I agree that Dec 30 and 31 fall in week 1;
but year 2014, not 2013.
Maybe I should rephrase my question: how do I get correct week year from "echo
(new DateTime('2013-12-30'))->format('W ');" ?
[2013-09-21 18:18:50] ras...@php.net
2013-12-30 ('Y W');" returns "2013 01" is correct. The 'Y' is the year. The ISO
8601 Year for 2013-12-30 is obviously 2013. However the ISO 8601 Week number
for
2013-12-30 is also just as obviously 1. So 2013 01 is correct.
And your next statement makes no sense either:
"So now we have two identical week number for year 2013 with a year difference
between dates ;)"
We are talking about Dec.30 and 31 in 2013. That is Monday and Tuesday. They
both fall in ISO week 1 and they are both in 2013. Wednesday Jan.1 2014 also
falls in ISO week 1 even though it is in 2014. That's how ISO weeks work.
Is your confusion that you think the 'Y' has to be associated with the 'W'
somehow? The 'Y' refers to the date you are formatting.
[2013-09-21 18:05:44] glavic at gmail dot com
@rasmus: I never said nothing about first or last week of the month containing
dates from before/after year. You probably agree with statement that the last
week of the year 2013 (and first week of the year 2014) is from 2013-12-30 to
2014-01-05?
I reported this, not because what you said, but because code "echo (new
DateTime('2013-12-30'))->format('Y W');" returns "2013 01" which is incorrect,
and for me this is bug. This should, like I already said in report, return
"2014 01".
Code "echo (new DateTime('2012-12-31'))->format('Y W');" also returns "2013
01". So now we have two identical week number for year 2013 with a year
difference between dates ;)
[2013-09-21 14:33:53] ras...@php.net
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
[2013-09-21 11:04:29] glavic at gmail dot com
Description:
DateTime::format('W') returns wrong week number when date is 2013-12-30 or
2013-12-31.
Test script:
---
setISODate(2013, $w);
print_r($dt);
echo $dt->format('Y W') . "\n\n";
}
# see this script running on all php versions http://3v4l.org/9aua5
Expected result:
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 01 # or 2013 53, but surely not 2013 01 !!!
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
Actual result:
--
DateTime Object
(
[date] => 2013-12-23 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 52
DateTime Object
(
[date] => 2013-12-30 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2013 01
DateTime Object
(
[date] => 2014-01-06 11:02:12
[timezone_type] => 3
[timezone] => UTC
)
2014 02
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #65730 [Nab]: DateTime::format('W') returns wrong week number
Edit report at https://bugs.php.net/bug.php?id=65730&edit=1
ID: 65730
Updated by: der...@php.net
Reported by:glavic at gmail dot com
Summary:DateTime::format('W') returns wrong week number
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Nope, we won't delete it so that we can point other people to it in the future.
Previous Comments:
[2013-09-21 18:51:06] glavic at gmail dot com
Ah, I found it, it is 'o' format character.
Sorry for your trouble. Can you delete this failed bug report? ;)
Tnx
[2013-09-21 18:48:10] glavic at gmail dot com
I made a copy/paste typo before, but that doesn't matter now because you said
that 'Y' returns the year of the date, which is totally correct, where was my
head...
I understand what you are saying; I agree that Dec 30 and 31 fall in week 1;
but year 2014, not 2013.
Maybe I should rephrase my question: how do I get correct week year from "echo
(new DateTime('2013-12-30'))->format('W ');" ?
[2013-09-21 18:18:50] ras...@php.net
2013-12-30 ('Y W');" returns "2013 01" is correct. The 'Y' is the year. The ISO
8601 Year for 2013-12-30 is obviously 2013. However the ISO 8601 Week number
for
2013-12-30 is also just as obviously 1. So 2013 01 is correct.
And your next statement makes no sense either:
"So now we have two identical week number for year 2013 with a year difference
between dates ;)"
We are talking about Dec.30 and 31 in 2013. That is Monday and Tuesday. They
both fall in ISO week 1 and they are both in 2013. Wednesday Jan.1 2014 also
falls in ISO week 1 even though it is in 2014. That's how ISO weeks work.
Is your confusion that you think the 'Y' has to be associated with the 'W'
somehow? The 'Y' refers to the date you are formatting.
[2013-09-21 18:05:44] glavic at gmail dot com
@rasmus: I never said nothing about first or last week of the month containing
dates from before/after year. You probably agree with statement that the last
week of the year 2013 (and first week of the year 2014) is from 2013-12-30 to
2014-01-05?
I reported this, not because what you said, but because code "echo (new
DateTime('2013-12-30'))->format('Y W');" returns "2013 01" which is incorrect,
and for me this is bug. This should, like I already said in report, return
"2014 01".
Code "echo (new DateTime('2012-12-31'))->format('Y W');" also returns "2013
01". So now we have two identical week number for year 2013 with a year
difference between dates ;)
[2013-09-21 14:33:53] ras...@php.net
PHP uses the ISO 8601 standard for day, month and week numbers. This is pretty
clearly documented and if you read ISO 8601 it states that the first week of
the
year is "the week with the year's first Thursday in it" and since ISO 8601
weeks
start on Mondays, it is quite normal for the first ISO week to contain days
from
a previous year. If they didn't then it would be impossible to consistently
start
weeks on Mondays since Jan.1 is not always a Monday. If you apply the ISO 8601
definition to the dates in question here you will find PHP is quite correct
here.
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
https://bugs.php.net/bug.php?id=65730
--
Edit this bug report at https://bugs.php.net/bug.php?id=65730&edit=1
Bug #63917 [Opn->Dup]: SplObjectStorage: Iteration of all the objects is not possible after detach()
Edit report at https://bugs.php.net/bug.php?id=63917&edit=1
ID: 63917
Updated by: le...@php.net
Reported by:LastDragon at yandex dot ru
Summary:SplObjectStorage: Iteration of all the objects is
not possible after detach()
-Status: Open
+Status: Duplicate
Type: Bug
Package:SPL related
Operating System: all
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This is duplicate of bug #65629 (https://bugs.php.net/bug.php?id=65629).
Previous Comments:
[2013-01-09 15:18:22] ashn...@php.net
The following patch has been added/updated:
Patch Name: bug63917.phpt
Revision: 1357744702
URL:
https://bugs.php.net/patch-display.php?bug=63917&patch=bug63917.phpt&revision=1357744702
[2013-01-09 06:05:45] LastDragon at yandex dot ru
> Are the "Expected" and "Actual" blocks reversed on this initial report?
Yes. Sorry. Unfortunately I cannot edit this blocks :(
[2013-01-08 21:05:06] ashn...@php.net
Are the "Expected" and "Actual" blocks reversed on this initial report? I came
searching for an SplObjectStorage bug where attempting to foreach() it and
detach all its members was failing to detach the final member. This bug report
looks like it reports exactly that, if you switch the Expected and Actual
blocks.
In my case, a foreach() around one SplObjectStorage object that performs a
detach() per member is finishing the foreach() loop while leaving one member
still attached. I can do a second foreach() on the SplObjectStorage object,
and this time it does see the remaining one member and detaches it
successfully. I suspect, as this bug report seems to specifically say, that
the detach() operation in the foreach() is causing an off-by-one error or is
implicitly calling one of the Iterator methods in a way that throws off the
foreach()'s Iterator steps.
[2013-01-06 11:25:18] LastDragon at yandex dot ru
Description:
Iteration of all the objects is not possible after the detach method was called.
Test script:
---
attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
var_dump($s->count());
foreach ($s as $v) {
var_dump($v);
$s->detach($v);
}
var_dump($s->count());
Expected result:
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(1)
Actual result:
--
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#3 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63917&edit=1
Bug #65629 [Com]: SplObjectsStorage::detach() rewinds internal pointer
Edit report at https://bugs.php.net/bug.php?id=65629&edit=1
ID: 65629
Comment by: le...@php.net
Reported by:alan dot bem at gmail dot com
Summary:SplObjectsStorage::detach() rewinds internal pointer
Status: Verified
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Assigned To:levim
Block user comment: N
Private report: N
New Comment:
Bug #63917 is a duplicate of this one (has a phpt uploaded -- might be useful).
Previous Comments:
[2013-09-21 22:58:59] le...@php.net
Related To: Bug #63917
[2013-09-12 22:49:38] le...@php.net
Regardless of whether this is a bug, in general modifying a structure during
iteration has undefined behavior. I will look a bit into this and see what
might
be done.
[2013-09-07 03:14:18] alan dot bem at gmail dot com
Description:
It seems that SplObjectsStorage::detach() internally rewinds its array pointer.
PHP versions from 5.1.0 to 5.5.3 are affected.
Test script:
---
// To see this live, go to: http://3v4l.org/MAELj
val = $val; }
}
$storage = new SplObjectStorage;
for($i = 1; $i <= 10; $i++) {
$storage->attach(new A($i));
}
$iterations = 0;
$storage->rewind();
while ($storage->valid()) {
$iterations++;
$object = $storage->current();
echo 'Iteration #' . $iterations . ' with object A(' . $object->val . ')';
$storage->next();
if($iterations === 2 || $iterations === 8) {
$storage->detach($object);
echo ' - deleted Object A(' . $object->val . ') ';
}
echo PHP_EOL;
}
echo 'Number of iterations: ' . $iterations . PHP_EOL;
Expected result:
Iteration #1 with object A(1)
Iteration #2 with object A(2) - deleted Object A(2)
Iteration #3 with object A(3)
Iteration #4 with object A(4)
Iteration #5 with object A(5)
Iteration #6 with object A(6)
Iteration #7 with object A(7) - deleted Object A(7)
Iteration #8 with object A(8)
Iteration #9 with object A(9)
Iteration #10 with object A(10)
Number of iterations: 10
Actual result:
--
Iteration #1 with object A(1)
Iteration #2 with object A(2) - deleted Object A(2)
Iteration #3 with object A(1)
Iteration #4 with object A(3)
Iteration #5 with object A(4)
Iteration #6 with object A(5)
Iteration #7 with object A(6)
Iteration #8 with object A(7) - deleted Object A(7)
Iteration #9 with object A(1)
Iteration #10 with object A(3)
Iteration #11 with object A(4)
Iteration #12 with object A(5)
Iteration #13 with object A(6)
Iteration #14 with object A(8)
Iteration #15 with object A(9)
Iteration #16 with object A(10)
Number of iterations: 16
--
Edit this bug report at https://bugs.php.net/bug.php?id=65629&edit=1
Req #49967 [Asn->Csd]: Custom iteration cannot return keys other than ints or strings
Edit report at https://bugs.php.net/bug.php?id=49967&edit=1
ID: 49967
Updated by: le...@php.net
Reported by:an0nym at narod dot ru
Summary:Custom iteration cannot return keys other than ints
or strings
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.0
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
As of PHP 5.5, this is now fixed.
Previous Comments:
[2009-11-11 12:13:28] col...@php.net
This is indeed a limitation of the iteration process itself, nothing specific
to splobjectstorage.
[2009-10-23 10:27:31] an0nym at narod dot ru
Ah, it seems that foreach can't handle anything non-scalar as a key. What a
pity.
I think this should be changed in the future, because it limits the use of
Iterators. For instance, I can't use something like:
$data)
{
var_dump ($object, $data);
}
?>
[2009-10-23 10:08:10] an0nym at narod dot ru
Description:
Iteration over SplObjectStorage returns unexpected results: internal index =>
associated object instead of object => associated data.
Reproduce code:
---
$data)
{
var_dump ($object, $data);
}
?>
Expected result:
object(stdClass)#2 (0) {
}
string(1) "a"
object(stdClass)#3 (0) {
}
string(1) "b"
Actual result:
--
int(0)
object(stdClass)#2 (0) {
}
int(1)
object(stdClass)#2 (0) {
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=49967&edit=1
Bug #60338 [Com]: SplFixedArray::key returns index for invalid keys
Edit report at https://bugs.php.net/bug.php?id=60338&edit=1 ID: 60338 Comment by: le...@php.net Reported by:g...@php.net Summary:SplFixedArray::key returns index for invalid keys Status: Open Type: Bug Package:SPL related PHP Version:5.4SVN-2011-11-19 (SVN) Block user comment: N Private report: N New Comment: I personally don't see why we should bring this into line with array, ArrayObject and ArrayIterator behavior. The fact of the matter is simple: you are calling `key()` on an iterator that is not in a valid state; therefore the behavior is undefined. The fact that array and the other classes you mention return `NULL` is an implementation detail, the only one of which I believe is guaranteed is the case of an array. Previous Comments: [2011-11-19 13:38:53] g...@php.net Apparently the Expected Output is achieved when using key() instead of SplFixedArray::key(). See http://codepad.viper-7.com/I3REjD. Thanks to NikiC for pointing it out. [2011-11-19 13:32:44] g...@php.net Description: SplFixedArray::key() will return a value even when the key does not exist in the SplFixedArray. This does not conform to the behavior we have in regular arrays, ArrayObject and ArrayIterator. SplFixedArray::key() should return NULL when the current key does not exist to conform. Test script: --- http://codepad.viper-7.com/4hWmUn Expected result: NULL NULL NULL NULL Actual result: -- int(3) NULL NULL NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=60338&edit=1
Bug #61754 [Com]: pdo_pgsql fails on make
Edit report at https://bugs.php.net/bug.php?id=61754&edit=1 ID: 61754 Comment by: jose dot nobile at gmail dot com Reported by:gencer at gencgiyen dot com Summary:pdo_pgsql fails on make Status: No Feedback Type: Bug Package:PDO related Operating System: CentOS 5.8 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I have 2 Centos Servers 6.4 (Final), the second with was updated with yum update, doesn't exists any additional repository different of CentOS repositories. In the first server PHP compile fine, in the second not. The first is not updated, but yum show the next will be updated (it can help you) Installing: kernel x86_64 2.6.32-358.18.1.el6updates 26 M kernel-devel x86_64 2.6.32-358.18.1.el6updates 8.2 M Updating: bind x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 4.0 M bind-chrootx86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 71 k bind-libs x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 878 k bind-utils x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 182 k busyboxx86_64 1:1.15.1-16.el6_4 updates 611 k cpuspeed x86_64 1:1.5-20.el6_4 updates 37 k db4x86_64 4.7.25-18.el6_4updates 563 k db4-cxxx86_64 4.7.25-18.el6_4updates 588 k db4-devel x86_64 4.7.25-18.el6_4updates 6.6 M db4-utils x86_64 4.7.25-18.el6_4updates 130 k device-mapper-multipathx86_64 0.4.9-64.el6_4.2 updates 112 k device-mapper-multipath-libs x86_64 0.4.9-64.el6_4.2 updates 175 k dhclient x86_64 12:4.1.1-34.P1.el6_4.1 updates 316 k dhcp x86_64 12:4.1.1-34.P1.el6_4.1 updates 816 k dhcp-commonx86_64 12:4.1.1-34.P1.el6_4.1 updates 141 k glibc i686 2.12-1.107.el6_4.4 updates 4.3 M glibc x86_64 2.12-1.107.el6_4.4 updates 3.8 M glibc-common x86_64 2.12-1.107.el6_4.4 updates 14 M glibc-develx86_64 2.12-1.107.el6_4.4 updates 974 k glibc-headers x86_64 2.12-1.107.el6_4.4 updates 605 k hplip-common x86_64 3.12.4-4.el6_4.1 updates 74 k httpd x86_64 2.2.15-29.el6.centos updates 821 k httpd-develx86_64
Bug #61859 [Com]: pdo fails on make
Edit report at https://bugs.php.net/bug.php?id=61859&edit=1 ID: 61859 Comment by: jose dot nobile at gmail dot com Reported by:gencer at cmail dot cm Summary:pdo fails on make Status: Open Type: Bug Package:Compile Failure Operating System: CentOS 5.8 x86_64 PHP Version:5.4.1 Block user comment: N Private report: N New Comment: I have 2 Centos Servers 6.4 (Final), the second with was updated with yum update, doesn't exists any additional repository different of CentOS repositories. In the first server PHP compile fine, in the second not. The first is not updated, but yum show the next will be updated (it can help you) Installing: kernel x86_64 2.6.32- 358.18.1.el6updates 26 M kernel-devel x86_64 2.6.32- 358.18.1.el6updates 8.2 M Updating: bind x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 4.0 M bind-chrootx86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 71 k bind-libs x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 878 k bind-utils x86_64 32:9.8.2-0.17.rc1.el6_4.6 updates 182 k busyboxx86_64 1:1.15.1-16.el6_4 updates 611 k cpuspeed x86_64 1:1.5- 20.el6_4 updates 37 k db4x86_64 4.7.25- 18.el6_4updates 563 k db4-cxxx86_64 4.7.25- 18.el6_4updates 588 k db4-devel x86_64 4.7.25- 18.el6_4updates 6.6 M db4-utils x86_64 4.7.25- 18.el6_4updates 130 k device-mapper-multipathx86_64 0.4.9- 64.el6_4.2 updates 112 k device-mapper-multipath-libs x86_64 0.4.9- 64.el6_4.2 updates 175 k dhclient x86_64 12:4.1.1-34.P1.el6_4.1 updates 316 k dhcp x86_64 12:4.1.1-34.P1.el6_4.1 updates 816 k dhcp-commonx86_64 12:4.1.1-34.P1.el6_4.1 updates 141 k glibc i686 2.12- 1.107.el6_4.4 updates 4.3 M glibc x86_64 2.12- 1.107.el6_4.4 updates 3.8 M glibc-common x86_64 2.12- 1.107.el6_4.4 updates 14 M glibc-develx86_64 2.12- 1.107.el6_4.4 updates 974 k glibc-headers x86_64 2.12- 1.107.el6_4.4 updates 605 k hplip-common x86_64 3.12.4- 4.el6_4.1 updates 74 k httpd x86_64 2.2.15- 29.el6.centos updates 821 k httpd-develx86_64
