The strtotime function has a strange problem.

The strtotime function has a strange problem.

Var_dump (strtotime ('20140901'); // output bool (false) var_dump (strtotime ('20160901'); // output int (1441185010)

It's strange, why are the two results different?

Reply to discussion (solution)

I returned two false values in PHP5.6. what version is your PHP.

I returned two false values in PHP5.6. what version is your PHP.

I am a 64-bit virtual machine in PHP Version 5.3.3 and centos6.4. the first normal output is false, and the second is incorrect.
What is the problem?

I don't know what you want to do?
Strtotime parses the date and time descriptions of any English text into Unix timestamps.
Echo strtotime ('2014/1/11 ');
If you want to convert a timestamp to a date, use date.

I don't know what you want to do?
Strtotime parses the date and time descriptions of any English text into Unix timestamps.
Echo strtotime ('2014/1/11 ');
If you want to convert a timestamp to a date, use date.

Modifier. date_format.php

function smarty_modifier_date_format($string, $format="%b %e, %Y", $default_date=null){    if (substr(PHP_OS,0,3) == 'WIN') {           $_win_from = array ('%e',  '%T',       '%D');           $_win_to   = array ('%#d', '%H:%M:%S', '%m/%d/%y');           $format = str_replace($_win_from, $_win_to, $format);    }    if($string != '') {        return strftime($format, smarty_make_timestamp($string));    } elseif (isset($default_date) && $default_date != '') {        return strftime($format, smarty_make_timestamp($default_date));    } else {        return;    }}

Shared. make_timestamp.php

Function smarty_make_timestamp ($ string) {if (empty ($ string) {$ string = "now" ;}/ ** This is a temporary emergency solution I have developed, the actual cause is not found. If (strlen (int) $ string) = 10) {return (int) $ string;} */$ time = strtotime ($ string ); // when processing the timestamp, the first timestamp returns false normally, but the second returns an integer that does not know how to obtain it, the result is inconsistent with $ string. The result is naturally incorrect if (is_numeric ($ time) & $ time! =-1) return $ time; // is mysql timestamp format of YYYYMMDDHHMMSS? If (preg_match ('/^ \ d {14} $/', $ string) {$ time = mktime (substr ($ string, 8, 2), substr ($ string, ), substr ($ string )); return $ time;} // couldn't recognize it, try to return a time $ time = (int) $ string; if ($ time> 0) return $ time; else return time ();}

When I use the smarty template to format the time, use this {$ aList [list]. inputtime | date_format: "% Y-% m-% d % H: % M: % S"}, but this time is incorrect, in the process of further error tracking, it is found that smarty directly treats the timestamp as a string and submits it to a function for processing. this function smarty_make_timestamp internally uses strtotime to directly process the string, return different values based on the processing result. The result is partially correct and partially incorrect. it seems that the time demarcation point is, so it is very strange.

Echo date ('Y-m-d H: I: S', 1441185010); // 17:10:10
1441185010 is a valid timestamp.

Strtotime -- parses the date and time descriptions of any English text into Unix timestamps
If you $ time = strtotime ($ string );
$ String is not the description of the date and time in English text, which is naturally incorrect.
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902171010 17:10:10
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902 00:00:00
Can your 1441185010 value be interpreted as, January 1 ????

Echo date ('Y-m-d H: I: S', 1441185010); // 17:10:10
1441185010 is a valid timestamp.

Strtotime -- parses the date and time descriptions of any English text into Unix timestamps
If you $ time = strtotime ($ string );
$ String is not the description of the date and time in English text, which is naturally incorrect.
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902171010 17:10:10
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902 00:00:00
Can your 1441185010 value be interpreted as, January 1 ????

Echo date ('Y-m-d H: I: S', 1451382400 );
// Output 17:46:40
Echo date ('Y-m-d H: I: S', strtotime ('20140901 '));
// Output 2400-09-06 14:51:38

Echo date ('Y-m-d H: I: S', 1441185010); // 17:10:10
1441185010 is a valid timestamp.

Strtotime -- parses the date and time descriptions of any English text into Unix timestamps
If you $ time = strtotime ($ string );
$ String is not the description of the date and time in English text, which is naturally incorrect.
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902171010 17:10:10
Echo date ('Y-m-d H: I: S', strtotime ('20140901'); // 20150902 00:00:00
Can your 1441185010 value be interpreted as, January 1 ????

My situation is not the same as that of direct output. in this case, I determine whether to directly return the timestamp or return the time processed by strtotime based on the strtotime result, normal strtotime processing timestamp returns false, but in my case, partial return false, such as 1441185010, but 1451382400 returns not false.

Because the timestamp you pass to strtotime is incorrect even if it is not false
Echo date ('Y-m-d H: I: S', 13591003898); // 19:26:50

Because the timestamp you pass to strtotime is incorrect even if it is not false
Echo date ('Y-m-d H: I: S', 13591003898); // 19:26:50

Thank you, moderator.
As I said before, my situation is not directly output, but output based on the results returned by strtotime.

My question is why
Strtotime ('20140901 ')
Is false;
While
Strtotime ('20140901 ')
But not false. In theory, should strtotime (10-bit timestamp) not output false?

That's a problem with your php.
All tested values are false.

That's a problem with your php.
All tested values are false.

It was tested that it was indeed a php version Problem. the above problem occurred in version 5.3. version 5.4 is false, but I don't know why?

The 5.2 version has the same problem as above. I don't know whether this is a bug or something.

You can read this post .... Http://bbs.csdn.net/topics/391822092