Hi Franck,
we 'lock' our applications in 2 ways:

1) by default users can insert only 10 records in every tables, this is the demo mode.
When customer buy the software he give us him data, we generate a key (a 10 char string) that we send back to the user.
He must insert this key into the application, then the software works in "full" mode.
(we have few others field which define: configuration, N. users allowed, ecc.)
2) the second one is similar to your one's, but we refer to the "number of days" as days of real use the software.
I mean: when we say: "test it for 60 days" we mean the the application works for 60 different days not "for the next 60 days".
I know this can be not good (we usually use the first case), but in this way we have resolved the problems you are asking for (it's a workaround....).
We don't have to worry about a 'real' clock/calendar, we simply store (in the registry, in a file) the different dates the application is run and when the max N. of days is reached the app doesn't works.
For this reason we usually set 30 days

I hope I was clear (my english... :) )
bye

>I have an application that can be downloaded, registered and then tested for 60 days.
>When this time is over the application refuses to work and asks for an unlock code instead.
>
>So far so good.
>
>However a user (not necessarily the most clever one) might come to the idea to set the
>system date back, and so get the application back to life.
>
>The question now is, how to track and catch that (betraying) behaviour.
>
>One idea would be to log the date/time upon application start and write this down
>at a safe place. Then, if a start-date is before another start date lock the application
>(witch again would have to be written to a safe place). Of course there must be
>a "time-buffer" to allow normal time-adjustments and summer/winter-time changes.
>
>Nicer would be, if the computer had an internal clock (like You have running hours on
>machines) that could be read.
>
>
>Any other ideas, experiences?
>
>Thanks for any replies