Various date problems

* We moved back the date 2 days, the remaining days increased by 2, instead of being zero. Resetting to today decresed by 2 instead of being zero.

We do allow some buffer for date adjustment. Maybe we'll have to make this tighter.

[...] reinsert another trial extension without success and just a product key could activate it and resolve the problem

I'll look into this.

* We moved ahead the date 2 days but still inside the trial period. Remaining trial days decresed by 2. Moving it back to today increased them by 2. Both this operation should disable the trial.

OK.

2) Moving the date when a product key is inserted will give problem just if the date is moved before the activation date.

I'm not quite sure what you mean. Can you explain this? Are you talking about custom license features?

3) Would be really helpful to have access to the last valid date seen from TurboActivate. Like this we can develop a subscription time based. In other words this is meaning that someone should make a virtual machine with the clock LOCKED (not working at all) and this should impossible for what i know.

We can add a function to let you validate custom license feature dates.

Hi Wyatt,ok day buffer is logical in an activation system but from all our test the activation complained just when we moved the date at least 2 days before the activation date of the trial. In all other cases the product remaining trial days was always a correct result. This in fact should be handled different and TurboActivate should be able to recognize when the user tryes to start the program in the past.

In fact according to my test i have a correction: moving ahead the date should not disable the trial (if you are still in the period) but returning back (also to the effective today date) shouldn't increase the remaining days and in fact disable the product completely.

For point 2, i meant that if someone tries to return before the activation date of a product key should loose the access to the product, without the need to add a custom feature. Right now we should implement our system to track the current date to be able to check a custom feature with a date inside.

For point 3, if you will allow me to validate generic dates (no matter if they are coming from features or from somewhere else), will be really helpful but this should be done without internet connection. In the case of a function we will for sure need also information regarding the remaining days from the current turboactivate date to the customdate.

And I have one more question.

How can I refresh a feature value in a client that did the offline activation and can't activate online? In an online one i can use isgenuine and activate, right?

This in fact should be handled different and TurboActivate should be able to recognize when the user tryes to start the program in the past.

You're right, we'll have to make that stronger.

How can I refresh a feature value in a client that did the offline activation and can't activate online? In an online one i can use isgenuine and activate, right?

Right, to get the latest feature values just re-activate. The same for offline activation.

For point 2, i meant that if someone tries to return before the activation date of a product key should loose the access to the product, without the need to add a custom feature. Right now we should implement our system to track the current date to be able to check a custom feature with a date inside.

If we add a new function that checks the validity of dates we can also ensure that the dates are sequential (i.e. no rollbacks).

Ok Wyatt, I will wait eagerly for the new functionalities and to test them

We noticed a bug related to the strange situation that is avoiding us to extend a trial that has been deactivated taking back the date before the activation date.

When we are using the new code to try to activate again, the usage count in the server is decrementing and locally it is not activating. This should not happen: the server should decrement the usage count for the trial code (or license if the bug exists there too) just if the client has succesfully activated the software.

You're talking about activation or deactivation failing when you change the time, correct? If that's what you're talking about, then you should know this is by design. Activation & Deactivation require valid date/time settings on the user's computer. Once you (a.k.a. your user) resets the time to the proper date/time then they'll be able to reactivate and it won't use an extra activation slot.

Unfortunately there's no way for the LimeLM servers to know that the user messed with their time. Hence the only solution:

1. Fix the time on the computer.
2. Activate again.

Does that make sense?

No, that case happened when i resetted back the time to the current time. The activation was stuck because of that strange bug that i spoke on the first post, but the time was correct and still the counter was decrementing but here i was receiving the message that the code was just used once, also when I changed the code to another one.

And after all it is possible to let you know that the date of the pc is wrong or that the activation didnt happen correctly. For the former you just need to include it in the first activation message that you are sending to the server; for the latter, after the client had operated the activation code, you just need to send back the activation result to the server and decrement at that point the counter.

In our in-house activation system this was "the next step" to implement: leaving the server in a "mixed state" until a confirmation would come.

[...] that strange bug that i spoke on the first post [...]

This bug?:

* We moved back the date 1 month, the remianing days went to zero and we are never been able to extend that trial anymore. We tryed to put back the date to today, reinsert the same code (that was having multiple usages), reinsert another trial extension without success and just a product key could activate it and resolve the problem

None of us can reproduce that bug. You can use multiple trial extensions, but you cannot use the same trial extension more than once. Plus, trial extension have nothing to do with activations (they're separate systems).

Can you give me a step-by-step of what you're doing and what is happening? Also, how it's different from what you expect.

Unluckily the steps are exactly like I said them but i will write them down again:1. I activated a trial extension and closed app.2. I went back one month.3. Started app, verfied the trial extension was disabled.4. Closed app and moved the date forth one month (to today).5. Started app, trial extension was still disabled.6. Tried to activate again with the same code (multiple usage) without success (agreeable)7. Tried to activate again with a different trial extension, without success same error of before8. Activated with a product key code successfully.

If you want tomorrow i can do the steps again to see if I will reproduce it too here.

I'll try to reproduce this later tonight.

7. Tried to activate again with a different trial extension, without success same error of before

OK, I see what you mean. You created a new trial extension, you used the exact same length and the exact same expires date and the trial extension said it was "in use" when you used it in your app.

This is by-design. The way to avoid this is to use a different expires date or a different trial length. Does that make sense?

No in fact. It will be really a rare case, but if an user will do the same operation that I did and he will be *regretful* we will need to give him a special trial extension when in fact a different one should fit, no matter the dates stored in it

OK -- we'll change the behavior so trial extensions with identical expires times & lengths will be able to extend the user's trial.

Hello Wyatt, do you have any news about this problem? It is quite a showstopper for us and until it will be fixed we won't be able to release our new licensing system.

We can push out a special release (v3.1.1) in the next couple of days that fixes just this bug, if you want. Would that work for you?

Would be helpful yes! Thank you!

Ok, we'll do that-- we'l try to get it out by Monday or Tuesday.

OK, we've fixed this for TurboActivate 3.1.1 out now (get it on your API page).

Wyatt, do you have any news about the trial date check?

With 3.1.3 I noticed that if someone returns before the activation date the trial will be disabled.

If someone moves inside the trial activation period the trial will never be disabled.If someone moves ahead in the future and then return back to today still the trial is not disabled.

We need still that someone can't return back to a date where the trial was active and gain days.

Wyatt, do you have any news about the trial date check?

That's coming with TurboActivate 3.2. We want to get it out in about 2 weeks.

We hope to have 3.2 out later today. But it's more likely it will be out tomorrow or Friday. Sorry for the delays. We want to make sure it's high quality before we release it.

Hello Wyatt,do you have any news on the release?

It's coming shortly.

TurboActivate 3.2 is now out -- we've fixed the trial extension bugs and we've added the IsDateValid() function.