On the ServerGrove blog today there's a new post talking about TTL collections in MongoDB - queries with a time-to-live set on the indexes - and includes how to use them in PHP.

MongoDB (v. 2.2+) provides a mechanism to expire data from collections by setting a TTL -time to live- on indexes. This is a great feature if you have data that needs to persist in the database for a specific period of time. The TTL feature allows you to expire data using the MongoDB daemon instead of having to create cron jobs to delete expired data. [...] The MongoDB daemon (mongod) checks regularly for documents in collections with a TTL and removes the expired documents.

Using it from PHP is relatively simple - all that's needed is a configuration parameter on the "ensureIndex" call setting an "expireAfterSeconds" value. There's also a bit included in the post for the Doctrine users out there, showing the docblock comment to use to set the value.

Kevin Schroeder has a new post to his site today wondering about the "max_input_time" setting for PHP and why some recommend it being a large number despite the (usually) fast time PHP has accepting input.

I asked a question on Twitter on why some of the recommend max_input_time settings seem to be ridiculously large. Some of the defaults I’ve seen have been upwards of 60 seconds. However, after thinking about it I was a little confused as to why a C program (i.e. PHP) would take so long to process string input. The reason I was thinking about this was because I was thinking about ways to protect PHP from denial of service attacks.

So he ran some tests to see just how effective changes in this setting could be and how much time a typical PHP request would need to take in input. Using a Zend Framework 2 HTTP client, he simulated POSTS and tracked the start and end times for a file upload. He includes the timing results in the post based on both this setup and a change to only post regular text-based form data.

Brian Moon has a reminder about date handling in PHP - days are not always 86400 seconds long, sometimes there's "leap seconds" included too. Thankfully, there's easy ways around it:

The problem with this is that it assume that there are only 86400 seconds in every day. There are in fact not. On days when the clocks change for daylight savings time, there are either 1 hour more than that or 1 hour less than that. In addition, there are also leap seconds put into our time system to keep us in line with the sun. There is one this year, 2012, on June 30th in fact. Since they don't happen with the regularity that daylight savings time does, it may be easy to forget those. Luckily, for this problem, the solution is the same.

His first solution involves letting strtotime do the work for him, internally calculating the leap seconds or any other issue that might come up. As an alternate solution, he also mentions "doing your math at noon" - this gives you enough leeway to make the offset leap seconds could cause a much smaller risk.

In this new post on his blog today, Derick Rethans points out something that might confuse some when it comes to date/time handling - a few seconds of "lag".

Bug report #35958 must have the most obscure one ever:

"strftime usually returns a string from the number of seconds since 1 jan 1970. Now, it lags and returns a string representing 23 seconds too late."

If you know what's going on though, it isn't really that weird.

He talks about the leap seconds that have been added to keep things straight, and how that's affecting PHP's built-in date/time functionality. He also shows an example of how you can get the "more correct" time versus the normal output...

In this new post on his blog today, Derick Rethans points out something that might confuse some when it comes to date/time handling - a few seconds of "lag".

Bug report #35958 must have the most obscure one ever:

"strftime usually returns a string from the number of seconds since 1 jan 1970. Now, it lags and returns a string representing 23 seconds too late."

If you know what's going on though, it isn't really that weird.

He talks about the leap seconds that have been added to keep things straight, and how that's affecting PHP's built-in date/time functionality. He also shows an example of how you can get the "more correct" time versus the normal output...