These two days in doing with a well-known card company's single sign-on integration (our products using Java writing, the other side of the program use. NET write) One of the parameters is a timestamp. That is, the current time relative to the ad 1970-1-1 00:00:00 of the number of seconds. According to the documents they gave me, I finished writing the Java section, the timestamp part is very simple, in a word:
Copy Code code as follows:
Private String Createtimestamp ()//timestamp
{
return System.currenttimemillis ()/1000 + "";
}
Use the System.currenttimemillis () method to get the number of milliseconds from January 1, 1970 0:0 0 seconds, divided by 1000 of the natural seconds. But the accident happened, and the time stamp I produced was a lot worse than the time stamp produced by their company. NET and Java are in the process of processing time and discrepancy.
. NET produces time in the current time zone, and the Java Currenttimemillis () method gets the time relative to GMT. China's time zone is +8 districts, so the time is a whole 8 hours bad!
So when the children meet again. NET is inconsistent with Java time, more to the time zone considerations, perhaps can find a solution:
Of course I will give the solution:
Method One: JVM runtime increment parameter, specify time zone-D user.timezone=gmt+08
Method Two: Set the time zone directly in the program. System.setproperty ("User.timezone", "GMT +08″");
Method Three: The direct plus 28800 is good (8hours*60min*60sec=28800)