How to deal with time zone problems in Java projects?
When we develop cross-region projects, users come from multiple different time zones, so we need to consider the processing of time zones.
For example, data creation time createDate. Regardless of the time zone, we are directly obtained from the server through System.currentTimeMillis () or new Date (). GetTime (), which is the number of milliseconds obtained according to the server time zone.
What about the time zone case?
Question 1: Milliseconds
Java’s milliseconds are from 1970 to the present. So in theory, at the same moment when data is created, the milliseconds in East Eighth District are 3 hours longer than in East Five District.
So do we need to record the time zone of the current operator when saving, and then when other people visit, calculate how to display the time based on the time zone difference?
For example, when it is saved in East 8 district, the number of milliseconds is 1520059818522, and then if a person in East 5 district wants to visit, does it need 1520059818522-(8-5) 36001000?
It doesn’t actually need to be that bothersome.
The old predecessors are super nice. I thought of this when formulating this rule. The so-called [milliseconds from 1970 to the present], if you are in the East 8 district, it is from 1970-1-1 to 8:00:00. Began to calculate.
In other words, no matter what time zone you are in, you get milliseconds at the same time, everyone is the same.
So you save a millisecond in the db, no matter where it is accessed, you can directly format the display, you do not need to consider the issue of offset.
Question 2: 7 * 24h
The same is true for timed tasks.
The number of milliseconds is indeed equal, but the number of hours obviously varies.
For example, in a project we are currently working on, a user in the Netherlands needs to place advertisements during peak hours at 8-9, 12-13, and 18-22, and not during other hours, then time zone issues must be considered. Because when your server is 8-9, the Dutch may be sleeping.
The time zone of the Netherlands is East 1. Assume our server is in East 8 and the server time is 7 hours ahead.
Then at 8:00 in the Netherlands, the server is at 15:00;
The Netherlands is at 22:00 PM on Monday and the server is at 5 AM on Tuesday.
I probably need a 24-digit system …
Or there is a simpler way, 7 * 24h is a total of 168 grids. I numbered these grids from left to right and top to bottom as 0-167, which is much cheaper.
After the user selects 1, 2, 25, 30, 120 in the foreground, I just need to add 7 to each number when saving.
Considering that addition and subtraction will produce numbers greater than 167, or less than 0, so a little calculation is needed.
//通过+168，再取余数，就可以规避掉不在0-168范围内的问题 int userTimezone = 1; int serverTimezone = 8; int originalHour = 120;//用户选择了一个120的格子 int serverHour = (originalHour - userTimezone + serverTimezone+168)%168;
But this also brings a problem, that is, when the user edits, you need to calculate back to the user’s time zone.
If you find this troublesome, you can also directly save the user’s selection and then judge it when applying it. In this case, it is when the advertisement is placed. It is logically possible, but for me, there are very few user edits, but there are many releases and analyses, so I still choose to store according to the server time uniformly.
It should be noted that if you store by server time like me, then your server time zone must not be changed for nothing, or the time zone of multiple servers is different. My approach is to set all servers to 0 time zone.
There are also some other problems, but for now these two are more typical, record them.
If you have similar issues, you can discuss them together.