The two strategies described by Raghav also demonstrate one of the fundamental aspects of Solidity programming: nothing will happen until a transaction triggers it. You can design the transfer function to check whether the address is allowed to keep holding its token, or you can create a reclaim function which gets the token back, but neither of those strategies "automatically" work at the 30-day mark.
Scheduling future events for a specific time is inherently impossible within a Solidity contract because your code only runs when a transaction or call triggers it. You can check that a time has passed, but you can't ensure that your code will run at that time.
Given that many applications do require scheduled events, some people are trying to work around this issue. The ethereum-alarm-clock project is under active development, it aims to let anybody schedule transactions by registering them with their EAC contract. It hasn't been deployed to the Ethereum mainnet yet as of 2018/08/16, but it looks like the 1.0 release will be there soon.
With that said, using their solution depends on trusting them to stick around. Their smart contract will execute your transaction, but based on my reading of their repositories, they only get around Solidity's fundamental constraints by running a Javascript server on a 5-minute interval which checks if any calls needs to get made. They have a very general solution to this problem, but you could probably write a simple node.js server yourself which handles just calling the reclaim() function at your desired interval.