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

go to bug id or search bugs for

Bug #75259 getTimestamp and ->format('U') both return 32-bit int
Submitted: 2017-09-26 13:34 UTC Modified: 2017-09-26 14:29 UTC
From: lewiscowles at me dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 7.0.23 OS: Ubuntu Xenial (64-bit)
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: lewiscowles at me dot com
New email:
PHP Version: OS:

 

 [2017-09-26 13:34 UTC] lewiscowles at me dot com 
Description:
------------
I expected to see > 32-bits (I'd really love to know how to get > 32bits of time-data if this is the expected behaviour)


Test script:
---------------
---
From manual page: http://www.php.net/datetime.gettimestamp
---
<?php

// PHP Get Integer Size (wouldn't expect 32-bit OS to deal with 64-bit Int's)
var_dump(PHP_INT_SIZE);   

// setup
$dt = new DateTime(PHP_INT_MAX << 1);

// should return 64-bit max shifted left once
var_dump(sprintf("%064b", $dt->format('U')));

// should return 64-bit max shifted left once
var_dump(sprintf("%064b", $dt->getTimestamp()));


Expected result:
----------------
// int(8)
// string(64) "0111111111111111111111111111111111111111111111111111111111111111"
// string(64) "0111111111111111111111111111111111111111111111111111111111111111"

// Note I may have the zero in the wrong place, can't remember if the most or least significant bit is supposed to be shifted, but you get the picture).

Actual result:
--------------
// int(8)
// string(64) "0000000000000000000000000000000001011001110010100111110111011010"
// string(64) "0000000000000000000000000000000001011001110010100111110111011010"

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-09-26 13:44 UTC] requinix@php.net
-Status: Open +Status: Not a bug -Type: Documentation Problem +Type: Bug
 [2017-09-26 13:44 UTC] requinix@php.net 
It works fine. https://3v4l.org/DigKO

Do not use the regular date string parsing functions (eg, new DateTime and strtotime) with a Unix timestamp because they treat the input as a formatted time string. https://3v4l.org/K5cNb
 [2017-09-26 13:45 UTC] danack@php.net 
What date or time, do you think:

new DateTime(PHP_INT_MAX << 1);

is meant to result in?
 [2017-09-26 13:56 UTC] lewiscowles at me dot com 
I expected to see > 32-bits, it's the first line of the description of the bug-report. But looks like I suck because it does return > 32-bits if I shift right by one on PHP_INT_MAX

The expected result was what I expected, although if it's a signed int, maybe there would be two zero's (one at beginning and one at end)
 [2017-09-26 14:04 UTC] lewiscowles at me dot com 
edit* both zero's at beginning
 [2017-09-26 14:08 UTC] lewiscowles at me dot com 
<?php

echo sprintf("%064b\n", PHP_INT_MAX);
echo sprintf("%064b\n", PHP_INT_MAX>>1);

0111111111111111111111111111111111111111111111111111111111111111
0011111111111111111111111111111111111111111111111111111111111111

What I mean is I expected to see these numbers or similar numbers from the DateTime function as they reflect the time-stamp passed in. 

There's a specification I'd like to implement that wants 48-bits of time. I apologize for being thick and shifting the wrong way in the original. I'm still not sure that the numbers output looked anything like what I expected.
 [2017-09-26 14:29 UTC] lewiscowles at me dot com 
Btw requinix@php.net. Totally solved for me +10000 you're awesome.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Jul 12 11:01:32 2025 UTC