My application depends upon time, so sometimes I have to move in time to future dates to do some application testing
I have one solution for this.
Change system date and time and restart the server, but I don't want to do this, this is very time-consuming task, and to change dates in future, affects my system's 365 office and tortoise HG and other applications too.
So basically want I want, I change date and time in server files or somehow tell JVM to point my fake clock, not to actual OS clock.
I know we have Mokito to mock the data, but my application is 20 years old without TTD.
I basically want to change the date and time which is Java jre is pointing to.
Or do we have a way out or API to modify the JRE time and date?
I hope you guys understand my problem if still doubt feel free to ask
Thanks for helping :)
I have developed one j2ee web application and generated .war file of it.
I have to share this war file with clients.
My problem is:
I don't want to give .war file for permanent use. Instead of to give it for trial period let's say for 30 days, so that they can know the features of application.
How to give trial period logic.
If I write logic using DB, they can reinstall the whole war file after one month and everything will start working again.
Client can also change the timing of system and then my control will go off.
I cannot access internet from application because it will be deployed only on intranet.
Please help me in any possible way of achieving this.
Thanks in advance
You very probably cannot do this perfectly (ever heard about cracked games and rooted phones?).
So it's a matter of making it difficult enough for the user to bypass your license, so that they won't bother.
The basic, simple idea is:
- Create a license for each user using your private key, that will contain the license expiry date
- Check the license for validity in your application, using a corresponding public key (both integrity and expiry date)
This will make sure the user won't get another month by just reinstalling.
Second simple step would be to write the last seen system time each time you exit the application, then check the system time on startup to make sure user didn't set the clock back (beware of daylight savings time though!).
That might get you covered for the two basic tricks to bypass the trial period. For more motivated users, you'll then need to add in more checks.
As can be seen below, system time and SoapUI's time value is different.
SoapUI using JRE time and that's why it should be a bug of Java's itself because; also below code gives: Venezuela Time
String tzn = TimeZone.getDefault().getDisplayName();
System.out.println(tzn);
What I've tried and failed:
Playing with regedit and changing time zone then get it back to correct.
Giving -Duser.timezone="Europe/Istanbul" at Control Panel/Java/JRE Settings/Runtime Parameters or giving same parameter inside the JAVA_OPTS variable.
Changing time or time zone and get it back.
I checked this question surely, correcting the timezone programmatically is doable but I need to correct SoapUI's timezone which affects automated test results. Because tests are time dependent.
I really tried hard to solve this issue, for days. I really don't know why the most plausible two methods are not working properly which:
Creating JAVA_OPTS system variable which has the value of: -Duser.timezone="Turkey"
Passing vm parameter from command line.
At last I gave up and set this parameter for each specific program, to be able to do this for SoapUI, go to SoapUI Home Path/bin folder and right click to soapui-pro.bat and choose to edit. (If you are using the community version, the name of the bat file will be different)
Then go to line 29 which starts with set JAVA_OPTS=-Xms128m... and insert time-zone parameter: -Duser.timezone="Turkey". Now execute the bat file, it's going to start to work properly!
I want to execute specific code in my app every 24h.
I know how to use AlarmManager but problem is I don't want that code to be executed if app isn't running.
I want it to be executed when app starts but only if 24h has passed after last execution.
It doesn't matter if more 24h has passed
For example if user opens my app for the first time code will execute. If it opens it again after 20min nothing will happen. if it opens it after 24h or more code will be executed.
I would save to a file, the time the program was started. You can check this before writing to see how long it has been.
Note: if there is a task you want to run at least 24h apart, you really want the last time the task was performed. e.g. if the application is opened every 8h you still want it to run.
Why don't you use Shared Preferences storage option provided by Android platform to store last access information and then act accordingly.
For more details refer this link: Android developer reference for Storage Options
I am getting the warning
Warning: sendmailpm.jsp modified in the future.
What does this mean?
You aren't allowed to modify anything in the past if doing so might change the future. You might cause a temporal paradox, which could corrupt the time stream and cause our entire reality to cease to exist.
Please do not modify that file.
JSP files are compiled. Many servers also allow you to replace the files on a running server. It then compares the timestamp of the compiled source and the timestamp of the jsp file to determine if it needs to recompile.
If the file is dated in the future, the jsp file will always be newer than the class. This gives you a warning.
Check the timestamp on the file. Perhaps someone created it on a computer with an incorrect clock, and now it appears to be "created in the future". Or perhaps the server has the incorrect date (check timezone settings).
Are there remote file servers involved? Clock drift between a web server and a file server can cause this error too.
To diagnose this further, you'd have to give us some hints - what jsp server, what OS, what filesystem?
During an Ant build, this warning can be output during a task.
[copy] Warning: foo\bar.txt modified in the future.
Ant's <copy> task by default won't copy files if the destination files are newer than the source. This saves much time and disk I/O. However you can override this behavior with the option <copy overwrite="true">. This tells Ant that you know what you're doing; overwrite the destination files regardless of their modification date. This will also suppress the warning.
If your code is residing on a FAT/FAT32 partition or ZIP file, this can be caused by the lack of precision in the FAT/ZIP filesystem's timestamping, which is 2 seconds (afaik). This can cause compiler / build tool output to be saved with a time slightly in the future, so that when the next build/deployment step (can be internal to a JSP container) is executed, the file will appear to be from the future and the warning is produced. Try using a different file system, e.g. NTFS on DOS/Windows boxes.
I had the same warning message from Apache Ant when trying to do a Java build on a FAT32 TrueCrypt partition. After ruling out other causes (timezone difference, clock off etc), I eventually found a hint on this, changed to an NTFS TrueCrypt partition and the warning disappeared.
Someone probably modified the file, then changed the time on the server. Try checking to see what time your box is set to and make sure it's correct. If it is, you can probably ignore that warning without any side effects.
Check whether system time is correct or not. If not sync it with Standard time for your zone. Then run your build file.
JSPs are compiled on-the-fly to servlets. The servlet container compares the "last modified" dates of both to see if the JSP has been changed and the servlet needs to be updated. A "last modified" date in the future indicates that something is wrong with the system clock, which is relevant because it could disrupt the abovementioned mechanism, leading to servlets that are not updated.
This is because, The time of the system is not current on which you are running the build file
If the java file that you are compiling has a time stamp that is beyond the current time of the system on which you are compiling...you will see this warning.
I modified the file on one machine and put it on another and tried compiling and came across this issue.
I got the same issue. The solution was: I changed the date and time on the build machine, so that it was in sync with the date and time on machine which the files were copied to.
If you have a jar file that you are trying to install at remote server. It might happen that remote server timestamp is not matching with your time zone. If your timezone is couple of hour ahead than the remote server then you might get this issue.
I also tried out one more trick..
When you create a JAR file, then go to system time and set a date couple of months back and try installing the JAR, you get this error.
I had this error too, but after reading some answers above i realized that is was due to the change i've done in the computer to some days ahead because of the test of a functionality that requires date manipulation.
Here is what happened:
1 - To perform Unit Test of a new implemented functionality i had to set the computer date to 4 days in the future.
2 - When i performed the test the compiler compiled the class automatically, as expected.
3 - Therefore when i was trying to rebuild the project the IDE detected that the file was (ironically) created in the future. (LoL - that's why i love Java you can even code in the future.).
So +1 #jmanning2k.
I hope it can help somebody facing this issue.
That warning appear to me too, it was because a previously changed the time in my computer to fix it because it was like 20 minutes ahead of the actual time