Hey Philippe,
The date, time, and timezone must all be accurate. We allow a certain number of minutes for drifting inaccurate clocks.
My guess is that the customer has an incorrect time zone set.
Computer time/date : how it must be accurate ?
Hello,
A few users tried to activate our product on a computer, where the clock wasn't correctly setup.It was just a matter of 10 hours or so, but the activation didn't work :- the ActivateEx() method is returning TA_OK- but the IsGenuineEx() method is failing
Of course, after setting the clock correctly, everything went fine.How the clock accurate must be ? How many hours ?
So in some case, we should guide the user to a proper solution, such as checking its clock.
Thank you. Philippe
Hello Wyatt,
Only a few minutes ?The clock can drift a lot if not synchronized on a regular basis, or if the user is travelling : don't you think it's risky to have such a low barrier ?How could we handle that in our product, so the user is not deactivated "by mistake" (which could be dramatic in our case) ?
Thank you. Philippe
>> "The clock can drift a lot if not synchronized on a regular basis, or if the user is travelling : don't you think it's risky to have such a low barrier ?"
We allow enough for drifting of cheap, innaccurate clocks. We don't allow enough for misconfigured clocks.
So, the solution is to always make sure the correct time/timezone/date is used. And no, traveling doesn't mess up the times -- LimeLM / TurboActivate use "universal" UTC times. Even if a customer is in New York, activates your software, and then travels to Paris and sets the new timezone on his/her computer, then everything will just work.
Hello,
Ok, thank you.
> And no, traveling doesn't mess up the times -- LimeLM / TurboActivate use "universal" UTC times. Yes I hope so !But you know, user do things that are not sometimes expected ...
I had a user with only 10 hours of clock delay, and he couldn't activate its software. LimeLM's limit seems very thin to me; anyway, we added a note on our tutorial, so users have more hints in case of trouble.Best. Philippe
>> "But you know, user do things that are not sometimes expected ..."
That's something we're all too aware of. 🙂
The good news (depending on how you look at it) is other things fail as a result of misconfigured date/time/timezone (including Windows Updates). So, users have multiple incentives to making sure their computer is configured correctly.
Hello Wyatt,
Wyatt wrote:> That's something we're all too aware of. 🙂Sure ? Another similar issue just happened yesterday (3rd one this month).The clock of one of our customer is Chile wasn't setup correctly, because the Chile changed its hours recently, but the Mac synchronisation system didn't took it into account : so the customer fixed it himself.Result : the product has been deactivated, and the customer couldn't understand why. After setting the clock in "auto synchronisation" mode, everything was back fine (despite the clock wasn't reflecting the current time there in Chile).
I know it seems silly, but this is the kind of weird stuff I'm talking about. I guess a higher barrier, let's say 3 or 4 hours, would be much more secure. Don't you think ?
Best. Philippe
I guess it wouldn't be the first time that we write code to workaround Operating System bugs. We'll definitely think about it. It won't be in 4.0, though.
Hi Wyatt,
Another vote for this feature, or at least allowing some customization of the time difference allowed. We have a number of customers who are frequently finding that their time sync is off and having to reset the clock and restart their servers - and depending on their setup, even something as simple as restarting may not be possible quickly or easily.
Thanks,Ian