8000 DateTime doesn't correctly parse PHP_INT_MIN timestamp · Issue #8000 · php/php-src · GitHub
[go: up one dir, main page]
Skip to content

DateTime doesn't correctly parse PHP_INT_MIN timestamp #8000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rybakit opened this issue Jan 25, 2022 · 1 comment
Closed

DateTime doesn't correctly parse PHP_INT_MIN timestamp #8000

rybakit opened this issue Jan 25, 2022 · 1 comment
Labels
Bug Extension: date Status: Invalid

Comments

@rybakit
Copy link
rybakit commented Jan 25, 2022

Description

The following code:

<?php

var_dump(PHP_INT_MIN);
var_dump((new DateTime("@-9223372036854775808"))->getTimestamp());
var_dump((new DateTime('-292277022657-01-27 08:29:52 UTC'))->getTimestamp());

Resulted in this output:

// Output for 8.1.0 - 8.1.2
int(-9223372036854775808)
int(-9223372036854775807) // wrong
int(-9223372036854775808)

// Output for 8.0.1 - 8.0.15
int(-9223372036854775808)
int(-922337203683200587) // wrong
int(-922337203683200588) // wrong

// Output for 7.4.11 - 7.4.27
int(-9223372036854775808)
int(-922337203683200587) // wrong
Fatal error: Uncaught Exception: DateTime::__construct(): Failed to parse time string (-292277022657-01-27 08:29:52 UTC) at position 11 (5): Double date specification ...

But I expected this output instead:

int(-9223372036854775808)
int(-9223372036854775808)
int(-9223372036854775808)

See https://3v4l.org/HdgS3.

PHP Version

PHP 7.4, 8.0, 8.1

Operating System

Linux, MacOS
@cmb69
Copy link
Member
cmb69 commented Jan 31, 2022

The totally wrong PHP 8.0 behavior has been fixed in the latest timelib version, so PHP 8.1 yields better results; I don't think this fix will be backported. The "slightly" wrong PHP 8.1 behavior is due to timelib_get_signed_nr() calling timelib_get_nr_ex() to get the actual number (without the sign), and that function calls strtoull(3) which saturates to the largest possible positive value. A possible fix would be to let strtoull(3) parse the sign as well.

Anyhow, this is actually an upstream issue; consider to report there, but see derickr/timelib#108 (comment).

@cmb69 cmb69 closed this as completed Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Extension: date Status: Invalid
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rybakit @cmb69
0