Daylight savings in TimeZone

It took a long time to get confused. The scenario is that European digital TV applications (DVB-T standard) can get the current UTC time from air real-time signals, the UTC time of the program forecast, and the so-called offset value. The offset value is inclusive. That is to say, if the offset value sent by the air signal is 2 during the UTC + 1 time zone, the offset value is 1 during the non-Daylight Saving period.
Customers in Europe reported that we had shown an hour ahead of schedule.
We made a test version to display the UTC time and offset value in the signal. The result is correct.
However, we have to ask the customer to record a stream of air signals to us, but we still cannot reproduce the problem here. It took a long time to check for problems in the code. I had to put it on hold.

Two weeks later, we came up with the first lesson. The only difference between the code stream test recorded by the customer and the test conducted by the customer is the time zone settings of the mobile phone. The mobile phones we tested were all set to "Beijing time" (UTC + 8 ). The customer's mobile phone is set to "Central Europe time, Daylight Saving Time" (UTC + 2 ).
This problem can be fixed after this setting. The time displayed in our App is one hour longer than the "local time" on the mobile phone.

The reason is that we take encoding for granted.
After running the program to obtain the air offset value, we use it to set the default TimeZone of the process.

TimeZone tz = TimeZone.getDefault();tz.setRawOffset(stream_offset * 1000);TimeZone.setDefault(tz);

Then, when you create a Calendar Object where the time needs to be displayed, do not pass the TimeZone. The expected TimeZone of setDefault () is used.

Calendar local_cal_start = new GregorianCalendar();local_cal_start.setTimeInMillis(epg_start_time);

Here, epg_start_time is "the date in milliseconds since January 1, 1970 00:00:00 UTC ".
In this way, when the time zone of the mobile phone is set to Beijing time ("UTC + 8") (when there is no renewal), the time is correctly displayed; when the time zone of the mobile phone is set to Central Europe ("UTC + 2", UTC), an additional hour is added.
Add a print observation here. Create a Calendar. If you set a summer date, local_cal_start.get (Calendar. DST_OFFSET) returns 3600000, that is, the offset when the hour is renewed. If you set a winter date, 0 is returned.
Here, the displayed time is offset when the cursor is added.

The test version we mentioned earlier shows that the UTC time is correct. In that version, the Calendar is created in this way.

Calendar local_cal_start = new GregorianCalendar(TimeZone.getTimeZone("GMT"));

Take a closer look at the API documentation.
TimeZone. setRawOffset (), Sets the offset in milliseconds from UTC
This time zone's standard time. this is the standard time, that is, raw offset.
TimeZone. getTimeZone ("GMT + 5"), return an object with a raw offset of + 5
Hours from UTC, and which does not use daylight savings.
The standard time of offset.
TimeZone. getDSTSavings (),
It seems that its function is equivalent to the get (Calendar. DST_OFFSET) of Calendar ). Returns 3600000 (1 hour)
Time zones that use daylight savings time and 0 for timezones that do
Not.

That is to say, we set the offset from the air signal that contains the offset when the cursor is used as the raw offset to the current TimeZone of the default process, and then add the cursor offset when creating the Calendar ar Based on the TimeZone, so it took an additional hour.

The solution is to change the code segment of getDefault ()/setRawOffset ()/setDefault () to the following.

timeZone = TimeZone.getTimeZone("GMT+" + (stream_offset / 3600));

When you need to create a Calendar,

Calendar local_cal_start =  new GregorianCalendar(MyBlaBla.timeZone);

To sum up, call TimeZone. getDefault () to obtain the system time zone settings. If the time zone has a timeout value, the Calendar will process the timeout value internally and automatically.
What we need to do is to ignore the system time zone settings of the mobile phone and set TimeZone and create Calendar based entirely on the offset time obtained from the air signal.

To add one thing, the DateFormat class has a protected Calendar. When formatting the date and time with DateFormat, be sure not to set TimeZone for the Calendar.