I tried
echo strtotime('129:00');
but it will have an empty output.
This
echo strtotime('03:00');
will have 1288339200 as the output.
I guess strtotime() won't accept huge values?? What's the alternative for strtotime() that will accept 129:00.
The alternative is to give strtotime() a time that actually means something. I know of no clocks that go up to 129 o'clock myself.
That's not to say there aren't any but I'm pretty old and I've traveled a bit. I'm sure I would have noticed something like this :-)
See the docs, which state:
The function expects to be given a string containing a US English date format
and end up pointing you here for valid time formats.
strtotime parses a date or a time (of the day, 24h clock) into UNIX timestamps. 129:00 is neither a date nor a time, so it returns false. It's not "too big", it's simply invalid input.
Related
date('Y-m-d H:i:s','1345453380000'); should return 2012-08-20 09:03:00 but instead it returns 44605-09-21 02:00:00
I understand the time difference of one day may be due to me not specifically setting timezone in the conversion, but 38k years in the future is a bit off, where am I doing it wrong?
Is it the trailing zeros?
I appreciate any pointers... (BTW That timestamp is how certain apps deliver them, I did not craft it myself)
When I getdate() that same timestamp the same issue happens, so I don't think my code is wrong, rather something is problematic with the trailing 0's...
But even if I use the from human to timestamp converted, with epoch converter, I get wrong results.
ONLY if I remove ALL zeros it seems to return a proper date.
Why?
Note again, the timestamp is how it comes from an online "diary" App, and Epoch converter IS able to read it!
(https://www.epochconverter.com/)
What is happening here is that the timestamp is in milliseconds, but PHP expects seconds. Epoch converter works fine with both seconds and milliseconds. What you have to do is call date('Y-m-d H:i:s', ($timestamp/1000));
Look at this demo.
date('Y-m-d H:i:s',(1345453380000/1000));
Above code converts milliseconds to seconds.
My Php server app receives data from a mobile application, including date/time strings.
One of these strings recently caused an exception when parsing the string into a DateTime instance because the timezone was formatted like this:
2017-03-14 17:56:42GMT+05.500
strtotime("2017-03-14 17:56:42GMT+05.500")
returns false, while
strtotime("2017-03-14 17:56:42GMT+05")
returns a epoch timestamp.
What is the best practice for handling such strings?
I could grep replace and offset by half an hour on the resulting timestamp, then designate a valid (by php standards) timezone.
It feels like I'm heading for a big pile of mud - maybe some kind person have a composer library to the rescue
So the problem was that my php app couldn't understand the 'GMT+05.500' time zone part, but can understand 'GMT+0530'.
I can use the regular expression below to find out if my input needs some string replacing and convert any decimal to the relevant offset in minutes
if(preg_match('/\+0?[\d]([,.:;_ ])([\d]{3})$/', $datetime, $matches){
//... convert 'GMT+05.500' to 'GMT+0530' by using a switch or actual calculation
Currently I haven't been able to find out if user-agents will use a locale/cultural specific separator character, so I assume a range og possibilities (the ',.;:_ ' part of the regexp). Maybe there is an ISO standard for how to format this, but user-agents being user-agents... :)
'GMT+0530' will also affect the resulting epoch timestamp when using strtotime() by the proper 30 minutes, so no data is lost.
I would like to change the timezone of a time like:
2015-08-24 01:30:40
so that it's in the America/Los_Angeles timezone, but the code below isn't working as expected:
$timedate = date_timezone_set(
date_create_from_format('Y-m-d h:i:s A', $row[timezone]),
new DateTimeZone('America/Los Angeles')
);
$row[timezone] successfully returns 2015-08-24 01:30:40 on it's own, but when I do it like this to try to change the timezone, it doesn't work.
All PHP code after that doesn't run. I have done lots of searching, but I can't figure out how to get this to work properly so can someone tell me what I am doing wrong?
Your call to date_create_from_format includes an A at the end of the format string - that looks specious to me, given that your value doesn't end with am or pm. Your use of h looks unlikely to be correct too, as that's for a 12-hour hour-of-day, which isn't useful when you don't have an am/pm indicator. I suspect you want a format of
Y-m-d H:i:s
That appears to match your sample string better...
Additionally, as noted in comments, your time zone ID should be 'America/Los_Angeles' rather than 'America/Los Angeles'.
I would also separate the various calls you have in this single large line of code, to make it easier to diagnose - that way you could tell that it's the parsing that's failing, rather than anything to do with the time zone. You have three separate operations here:
Parse a string to a datetime
Create a time zone object
Set the time zone in the datetime
Keeping those three in separate statements will make the code easier to read and easier to maintain. (In particular, you'd be able to find and correct these two problems independently...)
strtotime("25/03/1957") returns false. what will satisfy all of these date formats? i can't imagine how long it would take to actually make my own, so i hope there's already one out there you know of.
thanks!
Considering some dates are valid but can point to two different actual dates, no function will ever be able to "guess" the right format at all times...
To help with that, with PHP >= 5.3, a new function has been added : date_create_from_format -- but it doesn't exist with PHP < 5.3, unfortunately...
(See also DateTime::createFromFormat)
Still, in the example you took, the year 1957 is a possible source of problems : PHP generally works with UNIX Timestamps, when it comes to dates...
And, at least on 32-bits systems, those can only represent dates between 1970 and 2038 -- as they count the number of seconds since 1970-01-01.
To avoid this problem, it's often a good idea to use the DateTime class, with which (quoting) :
The date and time information is
internally stored as an 64-bit number
so all imaginable dates (including
negative years) are supported. The
range is from about 292 billion years
in the past to the same in the future.
(It will not solve the parsing problems with PHP < 5.3 ; but it'll solve the date-range problem...)
I've found that dateTime objects support a wider range of formats than the strtotime() function, and the timezone settings of your server also make a difference; but I ended up building a function that would replace '/' with '-' before using the string to date methods. I also test for valid, then try swapping the apparent dd and mm (25-03-2001 => 03-25-2001) if invalid before testing again.
I've been using PHP's strtotime() method to accept a date field on a form. I love how powerful it is, in how it will accept "Tomorrow", "Next Thursday", or (supposedly) any date representation and convert it to the Unix timestamp.
It's been working great -- until yesterday. Someone entered "2-4-10" and instead of logging Feb 4th, 2010, it logged April 10, 2002! So it expected Y-M-D instead of M-D-Y.
I thought maybe the problem was just using a 2-digit year, so we tried again with "2-4-2010". That logged April 2nd, 2010! At that point I just don't understand what strtotime() is doing. PHP.net says it expects a US English date format. Why then would it assume D-M-Y?
Is there a way around this? Or do I have to stop using strtotime()?
Note: I just now did a test. When you use slashes instead of hyphen/dashes, it works fine, even with 2/4/10. Why on earth does that matter? And if that's all it is, should I just run str_replace("-", "/", $input) on the form input before passing it to strtotime()?
The - indicates an ISO Date:
03-02-01 => 1. february 2003 (ISO)
01.02.03 => 1. february 2003 (European)
02/01/03 => 1. february 2003 (US)
The behavior of strtotime() is based largely on the GNU date input formats spec. But as powerful as it is, it shouldn't be expected to read minds. Allowing free-form user date input is asking for perpetual trouble.
I had this problem and solved it by doing exactly what you suggested - do a str_replace on the user-entered date to replace the dashes with slashes. This prevents strtotime from using an ISO date and solves the problem.
strtotime is by its very nature fuzzy, so you can't assume that it will always do what you want. If you enter 2010-04-02 then you would expect that to return 2nd April 2010, which is what strottime is trying to do. Running an str_replace from hyphens to slashes might mean that people entering in that format get the wrong date.
If you're running PHP 5.3 or above, consider date_parse_from_format() or for PHP 5.1 and above on Unix consider strptime(). Both functions take a format, so remove potential ambiguity (if you tell users what format you are expecting - if you're running an international site and have a text box labelled date which the user enters 2/4/2010 into then there is no way to know what their intended date is).