[PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Christian Stoller
Dear internals,

I have a strange bug with DateTime-modify('tomorrow') in PHP 5.3 on Linux.
Code to reproduce:

?php
$d = new DateTime('2013-02-05 06:33:33');
echo $d-format('Y-m-d H:i:s').\n;

$d-modify('tomorrow');
echo $d-format('Y-m-d H:i:s').\n;
?

Current output on Windows with PHP 5.3.14:
2013-02-05 06:33:33
2013-02-06 00:00:00

Current output on Linux (Debian) with PHP 5.3.3-7+squeeze15:
2013-02-05 06:33:33
2013-02-06 06:33:33

Can somebody verify this behavior? Are there any information about that or is 
there already something in the bugtracker? I have googled but couldn't find 
anything about that.


Best regards
Christian Stoller


Re: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Derick Rethans
On Tue, 12 Mar 2013, Christian Stoller wrote:

 I have a strange bug with DateTime-modify('tomorrow') in PHP 5.3 on Linux.
 Code to reproduce:
 
 ?php
 $d = new DateTime('2013-02-05 06:33:33');
 echo $d-format('Y-m-d H:i:s').\n;
 
 $d-modify('tomorrow');
 echo $d-format('Y-m-d H:i:s').\n;
 ?
 
 Current output on Windows with PHP 5.3.14:
 2013-02-05 06:33:33
 2013-02-06 00:00:00
 
 Current output on Linux (Debian) with PHP 5.3.3-7+squeeze15:
 2013-02-05 06:33:33
 2013-02-06 06:33:33
 
 Can somebody verify this behavior? Are there any information about 
 that or is there already something in the bugtracker? I have googled 
 but couldn't find anything about that.

The 5.3.14 result is correct. It was apparently a bug in earlier 5.3 
versions.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Jonathan Sundquist
Why would the result not preserve the time?


On Tue, Mar 12, 2013 at 11:04 AM, Derick Rethans der...@php.net wrote:

 On Tue, 12 Mar 2013, Christian Stoller wrote:

  I have a strange bug with DateTime-modify('tomorrow') in PHP 5.3 on
 Linux.
  Code to reproduce:
 
  ?php
  $d = new DateTime('2013-02-05 06:33:33');
  echo $d-format('Y-m-d H:i:s').\n;
 
  $d-modify('tomorrow');
  echo $d-format('Y-m-d H:i:s').\n;
  ?
 
  Current output on Windows with PHP 5.3.14:
  2013-02-05 06:33:33
  2013-02-06 00:00:00
 
  Current output on Linux (Debian) with PHP 5.3.3-7+squeeze15:
  2013-02-05 06:33:33
  2013-02-06 06:33:33
 
  Can somebody verify this behavior? Are there any information about
  that or is there already something in the bugtracker? I have googled
  but couldn't find anything about that.

 The 5.3.14 result is correct. It was apparently a bug in earlier 5.3
 versions.

 cheers,
 Derick

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Derick Rethans
No top posting please!

On Tue, 12 Mar 2013, Jonathan Sundquist wrote:
 
 On Tue, Mar 12, 2013 at 11:04 AM, Derick Rethans der...@php.net wrote:
 
   Current output on Windows with PHP 5.3.14:
   2013-02-05 06:33:33 
   2013-02-06 00:00:00
  
   Current output on Linux (Debian) with PHP 5.3.3-7+squeeze15:
   2013-02-05 06:33:33
   2013-02-06 06:33:33
  
   Can somebody verify this behavior? Are there any information about 
   that or is there already something in the bugtracker? I have 
   googled but couldn't find anything about that.
 
  The 5.3.14 result is correct. It was apparently a bug in earlier 5.3 
  versions.

 Why would the result not preserve the time?

Because tomorrow starts at midnight. You want +1 day.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

2013-03-12 Thread Nikita Popov
On Mon, Mar 11, 2013 at 8:42 PM, Dmitry Stogov dmi...@zend.com wrote:



 On Mon, Mar 11, 2013 at 10:27 PM, Nikita Popov nikita@gmail.comwrote:

 On Mon, Mar 11, 2013 at 9:50 AM, Dmitry Stogov dmi...@zend.com wrote:

 Hi Nikita,

 The patch looks good. I have just few comments

 - In ZEND_FE_FETCH handler PLAIN_OBJECT may have only STRING keys. I
 didn't get why you added unreachable code for INT and NULL.


 You are right about the NULL case, that can indeed not occur. But INT is
 possible, e.g. consider this:

 ?php
 foreach ((object) ['x','y','z'] as $k = $v) {
 var_dump($k);
 }

 this will give you keys int(0), int(1), int(2).


 Agree. I missed it.


 I'll remove the check for NULL.


 - At first, I fought, that it might be a good idea to change
 zend_user_it_get_current_key() to return SUCCESS/FAILURE instead of
 returning IS_NULL that has a special meaning. But after looking into the
 FE_FETCH code before the commit I understood where this NULL came from. I
 know that NULL key may not appear for plain array and objects but I'm not
 sure about iterators and generators. Now IS_NULL keys may mean that
 iterator returned it directly IS_NULL or may be it was returned because of
 some error conditions. Probably it's not a problem. What do you think?


 In foreach IS_NULL can't occur in an error condition, because the loop is
 already aborted when get_current_data provides NULL. IS_NULL can only
 happen when its explicitly provided (or handlers are incorrectly coded). I
 think the IS_NULL fallback is mainly important when the iterator is used
 for other things (like a dual it), to be sure that it'll always work. I
 don't think that it's important to distinguish between explicit NULL and
 failure NULL.


 Agree as well.


 I have one more question: Right now I added the
 zend_hash_get_current_key_zval API in zend_hash.c/h, which is a bit ugly
 because it has a zval dependency (unlike all the other code in there) and
 requires me to forward-declare the zval struct. Would it be better to move
 this somewhere else, e.g. zend_API.c/h? If so, can I still keep the same
 name (with the zend_hash_ prefix)? If I move it to zend_API, I won't be
 able to do the IS_CONSISTENT check anymore, is that a problem?


 I think we can move zval forward declaration (typedef struct _zval_struct
 zval;) from zend.h into zend_type.h.


I now merged the changeset in
https://github.com/php/php-src/commit/fcc6611de9054327441786e52444b5f8eecdd525(for
PHP-5.5 and master) with the forward declaration moved. Also updated
some array functions to use the new get_current_key_zval function :)

Nikita


Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

2013-03-12 Thread Dmitry Stogov
Hi Nikita,

I suppose it must fine now, but let me take a quick look tomorrow morning.

Thanks. Dmitry.

On Tue, Mar 12, 2013 at 8:43 PM, Nikita Popov nikita@gmail.com wrote:

 On Mon, Mar 11, 2013 at 8:42 PM, Dmitry Stogov dmi...@zend.com wrote:



 On Mon, Mar 11, 2013 at 10:27 PM, Nikita Popov nikita@gmail.comwrote:

 On Mon, Mar 11, 2013 at 9:50 AM, Dmitry Stogov dmi...@zend.com wrote:

 Hi Nikita,

 The patch looks good. I have just few comments

 - In ZEND_FE_FETCH handler PLAIN_OBJECT may have only STRING keys. I
 didn't get why you added unreachable code for INT and NULL.


 You are right about the NULL case, that can indeed not occur. But INT is
 possible, e.g. consider this:

 ?php
 foreach ((object) ['x','y','z'] as $k = $v) {
 var_dump($k);
 }

 this will give you keys int(0), int(1), int(2).


 Agree. I missed it.


 I'll remove the check for NULL.


 - At first, I fought, that it might be a good idea to change
 zend_user_it_get_current_key() to return SUCCESS/FAILURE instead of
 returning IS_NULL that has a special meaning. But after looking into the
 FE_FETCH code before the commit I understood where this NULL came from. I
 know that NULL key may not appear for plain array and objects but I'm not
 sure about iterators and generators. Now IS_NULL keys may mean that
 iterator returned it directly IS_NULL or may be it was returned because of
 some error conditions. Probably it's not a problem. What do you think?


 In foreach IS_NULL can't occur in an error condition, because the loop
 is already aborted when get_current_data provides NULL. IS_NULL can only
 happen when its explicitly provided (or handlers are incorrectly coded). I
 think the IS_NULL fallback is mainly important when the iterator is used
 for other things (like a dual it), to be sure that it'll always work. I
 don't think that it's important to distinguish between explicit NULL and
 failure NULL.


 Agree as well.


  I have one more question: Right now I added the
 zend_hash_get_current_key_zval API in zend_hash.c/h, which is a bit ugly
 because it has a zval dependency (unlike all the other code in there) and
 requires me to forward-declare the zval struct. Would it be better to move
 this somewhere else, e.g. zend_API.c/h? If so, can I still keep the same
 name (with the zend_hash_ prefix)? If I move it to zend_API, I won't be
 able to do the IS_CONSISTENT check anymore, is that a problem?


 I think we can move zval forward declaration (typedef struct _zval_struct
 zval;) from zend.h into zend_type.h.


 I now merged the changeset in
 https://github.com/php/php-src/commit/fcc6611de9054327441786e52444b5f8eecdd525(for
  PHP-5.5 and master) with the forward declaration moved. Also updated
 some array functions to use the new get_current_key_zval function :)

 Nikita



Re: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Ángel González
On 12/03/13 17:30, Derick Rethans wrote:
 On Tue, 12 Mar 2013, Jonathan Sundquist wrote:
 Why would the result not preserve the time?
 Because tomorrow starts at midnight. You want +1 day.

 cheers,
 Derick
Alternatively, $d-add(new DateInterval('P1D'));


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php