ID:1844928
 
So I'm rewritting some old PHP that was written for voting for top-sites and redeeming a reward for doing so. At this particular moment, I am having a problem with the PHP time() function returning 0000-00-00 00:00:00.

I'm going to assume this is happening because the top-site's web server is verifying by calling back to the PHP page with a query string. If I were to access said PHP page, time would return an actual timestamp. Yet for some reason when the callback is made it doesn't return anything. Anything useful at least.

Does anyone know why? Or a workaround? The solution needs to get the time of my web server before posting to the database.

Edit: Using the MySQL function now() seems to work as a workaround. Still curious as to why time() isnt working with the callback, though.
Given that PHP's time() doesn't take any arguments, and that there's not a whole lot anything external could do to mess with it, I suspect you're looking in the wrong place.
time() returns an integer, not a formatted timestamp string. MYSQL now() does though.

Maybe something is going wonky with how you're turning it into a timestamp.
http://php.net/manual/en/function.time.php

Do you have a timezone set at all?

It should be using the systems default time which in theory .. Should be set but it's worth checking that with the date shell command..
Yeah, it works whenever I visit pages. It just wasn't working with a callback request or whatever. I have no idea. I found a workaround though.

@SSX, That's really weird because I never even convrted it into a timestamp. I didn't even think about how it's supposed to return an integer. Weird.
Between what you've said here and what you said in IRC, I'm going to go out on a limb and say you're just inserting time() as a value directly into a MySQL timestamp field.

MySQL will take that poorly, Instead of that, you're going to want to insert something more akin to date('Y-m-d H:i:s')- which has a second parameter that takes the time, but it defaults to time(). You also might be better off just doing all of that on the database side, though, logic and all.
Old Query:
$time = time();
$query_result = $db->query("INSERT INTO cp_votelog (banner_id, account_id, type, amount, time, ip) VALUES ($banner_id, '$account_id', 'R', $AMT, $time, '$account_ip')");



New Query:
$query_result = $db->query("INSERT INTO cp_votelog (banner_id, account_id, type, amount, time, ip) VALUES ($banner_id, '$account_id', 'R', $AMT, now(), '$account_ip')");


Quick side question- Do I need to start using prepared statements? Or am I fine so long I sanitize everything? =[
Ah, yeah, that explains it- MySQL won't convert an integer ($time) to a timestamp because it's not exactly sure how to do it. An alternative would have been using the MySQL function "from_unixtime($time)" which would effectively tell it that $time is a "unix timestamp" (epoch value, which it is)

That being said, there's no reason not to continue using your new query. There's nothing wrong with keeping all of the issues involving time with the database.

As for prepared statements, that one kind of depends. If you were executing this exact query in a loop or something to that effect, then sure. If you're doing this once per page call and this is all it is, then you can safely ignore prepared statements and just properly escape_string your string inputs and make sure your numbers are safe and sane and you'll be fine without the overhead of a prepared statement.
Ah, good information. Thank you so much. :D