In the past two days, we have been doing single sign-on integration with a well-known one-card company (our product is written in Java, and the other party's program is written in .Net). One parameter is the timestamp. That is, the number of seconds that the current time is relative to 00:00:00 AD 1970-1-1. According to the documentation they gave, I completed the Java part. The timestamp part is very simple, in one sentence:
The code copy is as follows:
private String createTimestamp() //timestamp
{
return System.currentTimeMillis() / 1000 + "";
}
Use the System.currentTimeMillis() method to get the milliseconds from 0:00:00 on January 1, 1970, and dividing by 1000 is naturally the number of seconds. But an accident happened. The timestamp I generated was much different from the timestamp generated by their company. After checking the information, I found that there was a difference in processing time between .Net and Java.
The time generated by .Net is the current time of the current time zone, while the currentTimeMillis() method of Java is the time from GMT. The time zone where China is located is zone +8, so the time difference is 8 hours!
So when children's shoes encounter the time inconsistent between .Net and Java, consider the time zone more often, and maybe you can find a solution:)
Of course I will give a solution:
Method 1: Add parameters when JVM runs, specify time zone -D user.timezone=GMT+08
Method 2: Set the time zone directly in the program. System.setProperty("user.timezone","GMT +08");
Method 3: Just add 28800 (8hours*60min*60sec=28800)