>This is an approach I really like when I test software. In most cases You download
>a software and try it once. Then something important comes in between and the next time
>You have time to try the software is 30 days later. So this is just day two and not day 30.
>
>However it's still easy to betray. I can always set my system date to the 15th of July and
>work with it forever, since the software - checking on every startup - "thinks" it's still
>the 15th of July that has been logged already. In this case You would also need a counter
>that lets say allows to start the software 10 times a day. After that it would just add
>another day. Still this would allow a user to use the software on 300 days instead of 30
>until it finally quits its job.
>
>There must be better ways to do that.

You can improve security storing also the time the user launch/quit the app.
at startup if the actual time is < the the time stored for this day you add a day because user as set back the clock.
This way user must remember to set not only the date but also the time.
It's not the solution, but now the question is: what kind of users do you have? hackers? :))

What about an internal clock? (at the end should be the only way)
Don't say to clients "test it for 30 day" but: "test it for 100 hours".
Create an app timer, every timer.interval (let me say 1 minute) add the spent time to the global timing.
This way I don't have to worry about the calendar.
I don't think this would take to much cpu time, isn't it?