What's your time zone?
Java date and time class completely solved (3)
Page 3 of 3
Time area and Java are similar to Java and Solaris when the time zone information is related. Each time zone has a time zone ID identifier. In J2SE 1.3 and 1.4, this ID is a string, which is a list of Tzmappings files in the JRE / lib sub-directory in the J2SE installer. J2SE 1.3 only contains Tzmappings files, but J2SE 1.4 contains time zone data files in different parts of the world. JRE / LIB / ZI stores these files. In J2SE 1.4, Sun.util.Calendar.ZoneInfo acquires DST rules from these files. In Solaris, these time zone data files are stored in binary, so you can't see them. The time zone data file in J2SE 1.4 is different in Solaris.
The source code display of the getDefault method in the java.util.Timezone class is ultimately called the Sun.util.Calendar.ZoneInfo class GetTimezone method. This method returns a String parameter as the id for the required time zone. This default time zone ID is obtained from user.timezone (system) properties. If User.Timezone is not defined, it will try to get the ID from the user.country and java.home (system) properties. If it does not successfully find a time zone ID, it will use a "fallback" GMT value. In other words, if it does not calculate your time zone ID, it will use GMT as your default time zone.
Note that the System property is initialized in the initproperties method of the java.lang.system class. This is a local approach. Therefore, the source code is unavailable --- unless you go deep into the local code library in the J2SE distribution package. However, in the Windows system, the System property is initialized from the Windows registry, while in Linux / UNIX is initialized by environment variables. The Javadoc statement of the initproperties method, some attributes must be guaranteed to be defined "and they are listed. In the three System properties used by the GetDefault method of the Java.util.Timezone class, only Java.home is listed in Javadoc as a "guarantee" attribute.
Recommended solutions therefore, how do you make sure that Java can give you the correct time and date? With my point of view, the best way is to confirm that the default Timezone class of the Java Virtual Machine (JVM) is correct and is suitable for your geographic scope. How do you to make sure the default Timezone is correct and suitable? This is another new problem. Like most of the problems, there are many solutions. According to the source code of the java.util.Timezone.GetDefault method, the best way is to correctly set the user.timezone property. When you start a Java virtual machine, you can easily override the value set in the Java.lang.System.Initproperties method by using the -d command -Line parameter. E.g:
Java -duser.timezone = asia / jerusalem dateest
This command launches the DateTest class (which is listed in this article) and sets the user.timezone property to Asia / Jerusalem. You can also set the user.timezone property by using the setProperty method of the Java.lang.System class: System.SetProperty ("User.Timezone", "Asia / Jerusalem");
If there is no available time zone ID for you, then you can create a custom TimeZone using the setfault method of the Java.util.Timezone class to set it to the default time zone ---- just in the ITSinitializer class The same operation is the same.
Remember, in J2SE, most dates and time-related classes contain time zone information, including those format classes, such as Java.Text.DateFormat, so they are affected by the JVM's default time zone. However, when you create these classes, you can ensure that the correct time zone information makes it easier to set the default time zone of the entire JVM. And once you set it, you can ensure that all of these classes will use the same default time zone. However, the ancient language cloud, "everything is difficult".
So, try to contact and tame these Java dates / time!
Translated by Willpower, 2003.11.20
