php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #48225 DateTime parser doesn't set microseconds for "now"
Submitted: 2009-05-10 17:29 UTC Modified: 2016-10-05 20:01 UTC
Votes:20
Avg. Score:4.3 ± 1.0
Reproduced:20 of 20 (100.0%)
Same Version:11 (55.0%)
Same OS:8 (40.0%)
From: knut dot urdalen at gmail dot com Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: 5.*, 6CVS (2009-05-09) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: knut dot urdalen at gmail dot com
New email:
PHP Version: OS:

 

 [2009-05-10 17:29 UTC] knut dot urdalen at gmail dot com 
Description:
------------
The date()-function allow a 'u' format character in the formatting field as of PHP 5.2.2. The DateTime::format() function point to the same manual page for the formatting as the date() function and since DateTime actually store microseconds internally (as mentioned by Derick previously) I think it's a bug that it's not output correctly.

Reproduce code:
---------------
<?php
date_default_timezone_set('Europe/Oslo');
$datetime = new DateTime();
echo $datetime->format('Y-m-d H:i:s.u')."\n";
?>


Expected result:
----------------
The 'u' format character should output the microsecond that is internally stored in the DateTime object upon creation.

Actual result:
--------------
The 'u' format character always resolve to 00000.

Patches

bug48225 (last revision 2016-08-07 14:10 UTC by cmb@php.net)

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-05-10 17:38 UTC] jani@php.net 
See also bug #45554 and bug #47312
 [2011-01-23 16:20 UTC] jmdoren at ok dot cl 
I have the same problem
my OS : Fedora release 14 (Laughlin)
my php Version: PHP 5.3.5 (cli) (built: Jan 22 2011 00:55:37)
in my php.ini date.timezone=America/Santiago
my script: <?php echo date( 'd-m-Y G:i:s,u' ); ?>
my results:
23-01-2011 8:34:18,000000
23-01-2011 8:34:18,000000
23-01-2011 8:34:19,000000
23-01-2011 8:34:20,000000
....
 [2011-11-03 02:19 UTC] rewilliams at crystaltech dot com 
Still see it in 5.3.6 on OS X....
 [2012-02-24 17:46 UTC] kissifrot at gmail dot com 
PHP 5.3.10 on Win32 still has the bug, the "u" part is still at 000000.
 [2012-05-14 11:38 UTC] tdenev at kontrax dot bg 
OS: Slackware 13.37

$ php -v 
PHP 5.3.8 (cli) (built: Oct  9 2011 13:58:17) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans

still has this bug, the "u" part is still at 000000.
 [2012-08-01 13:19 UTC] arnoonline at gmail dot com 
I also have this bug within Linux Mint:

$ php -v
PHP 5.3.6-13ubuntu3.8 with Suhosin-Patch (cli) (built: Jun 13 2012 18:02:19) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
 [2016-08-07 10:09 UTC] cmb@php.net
-Summary: Microseconds output wrong in DateTime::format() +Summary: DateTime parser doesn't set microseconds for "now"
 [2016-08-07 10:09 UTC] cmb@php.net 
There are two similar but unrelated issues here.

Firstly, the microseconds are swallowed when formatting a datetime
using a locale with a decimal separator other than a dot. This has
already been analyzed in bug #67127.

Secondly, unless the microseconds are explicitly given, they are
simply set to 0 *internally*, see <https://3v4l.org/o4Lvt>. So
this is not related to formatting, but actually a parsing error.
Let's concentrate on this issue in this ticket.
 [2016-08-07 14:10 UTC] cmb@php.net 
The following patch has been added/updated:

Patch Name: bug48225
Revision:   1470579044
URL:        https://bugs.php.net/patch-display.php?bug=48225&patch=bug48225&revision=1470579044
 [2016-08-07 14:11 UTC] cmb@php.net
-Status: Assigned +Status: Analyzed
 [2016-08-07 14:11 UTC] cmb@php.net 
The culprit is in php_date_initialize()[1]. time() delivers the
Unix timestamp in seconds, and timelib_unixtime2local() and some
other functions expect it this way. Actually, these functions in
timelib should be adjusted, but that would break API
compatibility.

A workaround would be to retrieve the current microseconds in
php_date_initialize() and to set now->f appropriately. This should
only be done, if the have_time member of the timelib_time struct
is 0, to avoid using the current microseconds, if a (partial) time
is already given.

However, due to bug #72773 and
<https://github.com/derickr/timelib/issues/7> the attached patch
would cause BC breaks (what can be seen as some test cases fail
after applying the patch).

[1] <https://github.com/php/php-src/blob/PHP-7.0.10/ext/date/php_date.c#L2556>
 [2016-10-05 20:01 UTC] derick@php.net
-Status: Analyzed +Status: Closed
 [2016-10-05 20:01 UTC] derick@php.net 
The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Fixed for PHP 7.1.0 RC4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC