What's your time zone?
Java date and time class completely solved (2)
Page 2 of 3
First, the solution is based on the result of Java document information and the output of the DateTest class. I played a best gambling: Java virtual machine automatically sets a default time zone when the first time is running. For verification, I created an ITSInitializer class so that my application can run it when it is loaded (Launched). Here is my first try:
import java.util.TimeZone; import java.util.SimpleTimeZone; public class ItsInitializer {private static boolean s_initialized = false; (! s_initialized) private ItsInitializer () {} public static synchronized void initialize () {if {// Modifies the default Time Zone, Disables The Daylight Saving Time. SimpleTimezone DTZ = (SimpleTimezone) Timezone.GETDEFAULT (); DTZ.SetStartrule (0,0,0,0); DTZ.SETENDRULE (0, 0, 0); Timezone.SetDefault (dtz); s_initialized = true;}}}
In other words, I changed the Default Timezone of JVM, so it didn't have a daylight saving time (DST) rule, so you don't have to worry about adjusting it.
Later, J2SE 1.4 was released, so I was upgraded. But unexpected is: its ITSInitializer class cannot run. So I immediately went to investigate. Found a DateTest class output (for J2SE 1.4.1_01 on Windows 98):
Date = Tue May 06 05:31:03 IDT 2003Calendar = java.util.GregorianCalendar [time = 1052188263870, areFieldsSet = true, areAllFieldsSet = true, lenient = true, zone = sun.util.calendar.ZoneInfo [id = "Asia / Jerusalem ", offset = 7200000, dstSavings = 3600000, useDaylight = true, transitions = 143, lastRule = java.util.SimpleTimeZone [id = Asia / Jerusalem, offset = 7200000, dstSavings = 3600000, useDaylight = true, startYear = 0, startMode = 1, startMonth = 3, startDay = 1, startDayOfWeek = 0, startTime = 3600000, startTimeMode = 0, endMode = 1, endMonth = 9, endDay = 1, endDayOfWeek = 0, endTime = 3600000, endTimeMode = 0]], firstDayOfWeek = 1, minimalDaysInFirstWeek = 1, ERA = 1, YEAR = 2003, MONTH = 4, WEEK_OF_YEAR = 19, WEEK_OF_MONTH = 2, DAY_OF_MONTH = 6, DAY_OF_YEAR = 126, DAY_OF_WEEK = 3, DAY_OF_WEEK_IN_MONTH = 1, AM_PM = 0, HOUR = 5 , Hour_of_day = 5, minute = 31, second = 3, MilliseCond = 870, zone_offset = 7200000, DST_OFFSET = 3600000] You also saw it, J2SE 1.4's Timezone class Zone member is already an instance of SimpleTimezone. Instead, Sun.util.Calendar.ZoneInfo class. Therefore, I need to change its initializer to compatibility with the J2SE 1.4 platform:
import java.util.TimeZone; import java.util.SimpleTimeZone; public class ItsInitializer {private static boolean s_initialized = false; (! s_initialized) private ItsInitializer () {} public static synchronized void initialize () {if {// Modifies default time . zone, disables Daylight Saving Time TimeZone l_defaultTimeZone = TimeZone.getDefault (); int l_rawOffset = l_defaultTimeZone.getRawOffset (); String l_id = l_defaultTimeZone.getID (); SimpleTimeZone l_simpleTimeZone = new SimpleTimeZone (l_rawOffset, l_id, 0, 0, 0, 0, 0, 0, 0, 0); timezone.setdefault (l_simpletimezone); s_initialized = true;}}} I created a SimpleTimezone instance without DST rules, and assigned it to JVM's default Timezone. The second execution is more than the first Ok, because it does not consider an actual class for ZONE members of the Calendar class. Note that this second version is compatible ------ it works well on J2SE 1.3. Nothing can learn more than learning through personal experience, I want to get more experience, then I can completely solve this problem.
I think that during the daylight saving time (DTS), we will always adjust the computer's time, so we will never adjust the DST, so you can make JVM always set a default Time without Summer rules. Zone. The result is solved.
So we are happy to develop our applications through the above strategy, all things are very smooth. There are no more date and time contradictions and differences. When winter is coming, we re-adjusted your computer time back. In the program we have not encountered any dates and time issues, this is also grateful to ITSinitializer.
However, later discovered that I made another mistake, so I have to return to the original kind of irritability.
An unpredictable fault has passed, and the summer is coming again, and naturally has entered the summertime stage. I originally thought that there was no problem, so I used the above strategy to solve. On The Very Day We Moved to Dst, I Got TimeStamp DiscRepancies. What happened?
This year, I didn't physically adjust the time of the computer. I have configured our Sun servers to make us don't need to physically adjust the system clock. The Date command is a UNIX / Linux command to display the date and time of the current system. Date's Solaris version helps automatically adjust DST display using the Timezone profile. Similar to the work mechanism of Java's Calendar class. Therefore, if the Timezone profile is installed, you don't have to physically adjust the system clock. I believe that Linux can also do this.
Our Windows runs Windows XP, and we have not physically adjusted system time. We can configure the time zone in the Windows XP. The problem is coming, for DST, sometimes it will be automatically adjusted and sometimes adjustable, the following two pictures show this:
Figure 1. Time Zone with Automatic Dst Adjustment
Figure 2. Time Zone without Automatic Dst Adjustment. INTOUSTMATIC DST Adjustment
Translated by Willpower, 2003.11.18
