Dates 20 years in the future considered invalid

Question

Laravel validator doesn't accept dates that are more than 20 years in the future:

Route::get('test', function() {
    $input = ['date' => '2039-01-01'];
    $rule = ['date' => 'date'];
    $v = \Illuminate\Support\Facades\Validator::make($input, $rule);
    return 'Fails: '.$v->fails();
});

The following example returns true, despite the fact that the date is correct. But when I change 2039 to 2037, it works. How can I do to make the validator always return false?

Check this: https://stackoverflow.com/questions/3953333/maximum-time-php — Mayank Pandeyz, Jun 29 '18 at 10:03
I see there will be a problem in 2038, but its there a way to bypass this limit for the validation as I'm using dates and not UNIX timestamps? — JacopoStanchi, Jun 29 '18 at 10:11

score 3 · Accepted Answer · edited Jun 20 '20 at 09:12

3

From Wikipedia on Unix time:

On systems where the representation of Unix time is as a signed 32-bit number, the representation will end after the completion of 2,147,483,647 (2^31 - 1) seconds from 00:00:00 on 1 January 1970, which will happen on 19 January, 2038 UTC, with the exact time depending on the unpredictable leap seconds. This is referred to as the "Year 2038 problem" where the 32-bit signed Unix time will overflow and will take the actual count to negative.

And from Laravel Validation docs:

date

The field under validation must be a valid date according to the strtotime PHP function.

This seems to depend on whether PHP is compiled to use 32-bit timestamps or 64-bit timestamps (see discussions here). If you have a 32-bit PHP, your only way forward would be to write your own validator, that doesn't depend on PHP's date parsing (or move over to a 64-bit PHP).

edited Jun 20 '20 at 09:12

Community

1
1

answered Jun 29 '18 at 10:03

Amadan

191,408
23
240
301

Ok so is there a way to validate dates above 2038? After all it is just a character string (I'm talking about the dates not the timestamps). – JacopoStanchi Jun 29 '18 at 10:07
It is just a character string, but programmers are inherently lazy, and date parsing can be... nontrivial, so I totally understand the decision to hand it over to PHP's date parsing function. As I say in my belated edit, either get 64-bit PHP or write your own "just a character string" validation function. I'd vote for the former, if at all possible. – Amadan Jun 29 '18 at 10:15
Writing my own validation rule might be the solution, but the problem is that I also want to use the `after` validation rule to check that a given date is after another date. – JacopoStanchi Jun 29 '18 at 10:20
You can break each date string down as an array of string ['day', 'month', 'year'] then compare the given date against the other date using normal integer comparison. @JacopoStanchi – Oluwatobi Samuel Omisakin Jun 29 '18 at 10:23
Then that's two validators you'd need to write. My preference for switching to 64-bit PHP grows by the minute. You might also take a peek at [this article](https://stablekernel.com/friends-never-let-friends-implement-date-libraries/)... – Amadan Jun 29 '18 at 10:24
1

@OluwatobiSamuelOmisakin Yes but that would require to create yet another Rule. I might leave this problem for later for now. – JacopoStanchi Jun 29 '18 at 10:24

Dates 20 years in the future considered invalid

1 Answers1