Java and DST rules
Hello friends
We are in the process of upgrading our JVM to suport the latest DST changes that are going to be effective in Matrch 07.I understand how and where Java keeps the DST information but a question came up in the discussions that why does Java not rely on the OS for the DST information.As fasr as I understand teh underlying Operating Systems like Windows and Unix is cognizant of not only their own local Timezone but they are also aware of the DST rules applicable to different timezones.
Question is why can Java not leverage of the DST rules from theOS and
why does it manage it itself. The only answer I could think of is that JAVA has more elaborate functionality built around the DST and Timezones and may be the OSs do not provide a robust enough API to access the DST rules for different (non local) timezones.
Any thoughts and ideas will be appreciated. This is more for academic interest than anything else. I am pretty sure that there must have been a strong reason for the designers to take on the responsibility of managing Timezone/DST rules but I just don't know what.
Regards
Rajeev Bhogal
[1163 byte] By [
v2kea204a] at [2007-11-26 14:51:22]
# 1
Rajeev - I also would like to know why the JREs were designed this way. I can tell you that Sun has probably caused or will cause stress to companies that have to update the JREs on all desktops. Seems like a bad design decision to me.Jeff
# 2
I'll take a guess as to why.
Different Operating Systems handle timezones different. See http://en.wikipedia.org/wiki/Time_zoneJava tries to be cross platform and so it has to handle timezones itself.
Also see the Computing section in http://en.wikipedia.org/wiki/Daylight_saving_time#Computing
# 3
Sun had provided a patch to update the JRE.Sould another patch be also applied to update the OS?ThanksLeena
LGFa at 2007-7-8 8:39:32 >
# 4
I am using j2sdk1.4.2_08 and when i try to update the JRE with tzupdater. It gives me the following error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/tools
/tzupdater/TimezoneUpdater (Unsupported major.minor version 48.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Any idea why this is happening.
The read me file clearly states that the tool supports JDK/JRE releases 1.4 or later and on all supported platforms
I did not face any error when i tried to update another system with j2sdk1.4.1_02.
Is j2sdk1.4.2_08 not supported?
Message was edited by:
LGF
Message was edited by:
LGF
LGFa at 2007-7-8 8:39:32 >
# 5
sorry for the confusion. Once the classpath was set properly it worked fine
LGFa at 2007-7-8 8:39:32 >
# 6
Hey
I am also suffered with the same problem ,I have jdk142_05 version but when I am trying to update it then I getting the same error:-
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/tools/tzupdater/TimezoneUpdater (Unsupported major.minor version 48.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:703)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:133)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:320)
at java.net.URLClassLoader.access$400(URLClassLoader.java:93)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:678)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:239)
at java.lang.ClassLoader.loadClass(ClassLoader.java:516)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:460)
at java.lang.ClassLoader.loadClass(ClassLoader.java:448
Did anyone have solution?
Thanks in advance
Mukesh Negi
# 7
Sorry for late in posting the reply. It was on my watch list but it never generated an email. Thanks everyone for taking the time to throw your thoughts in. Jeff I agree with you, this is a problem for a lot of companies and unless we stumble across a credible answer from the people who designed it this way, we will have to call it a design issue.
LGF - Yes you have to update your OS as well, we are doing the same thing.
Mukesh Sorry but your issue seems to be classpath related only.
Regards
Rajeev Bhogal
# 8
I'm finding different results with JDK 1.4.2_05 patched with TZupdate and JDK1.4.2_13 both with no Windows OS update.
Both JREs correctly update the timestamp for the Mar 11, 2007 Spring forward an hour at 2am PST. However, both JREs don't update the timestamp for the Nov 4, 2007 Fall back an hour at 2am PST.
Anyone else seeing this problem?
I have tested the JDK 1.4.2_05 patched with TZupdate and MS Windows update and JDK1.4.2_13 with MS Windows update and seen the JRE correctly update for both DST PST time changes(Mar 11th and Nov 4th).
So why does the OS not have to be updated for Mar 11th, 2007, but does have to be updated for Nov 4th, 2007?
I haven't tried this scenario on Unix, but plan to soon. Any insight on why this mixed behavior without OS update would be appreciated.
Thanks for your help,
Bob
# 9
> Question is why can Java not leverage of the DST
> rules from theOS and why does it manage it itself.
Surprisingly, part of the answer is that different OSes use different timezone names for the same timezones. Some use the modern "America/Los_Angeles" style names, while some still use names like "PST" and "PDT" (or "PST8PDT"). Some (esp embedded) OSes don't even have a time zone concept.
For Java to provide a uniform interface with uniform names, they have to provide their own TimeZone library. I suppose they *could* have made the implementations on Windows, Linux, Solaris, etc., default to the OS implementations with a [long] array of name mappings from Java to OS names, but this gets tedious to implement and verify.
It also means depending on the OS to implement the timezones correctly, and historically, many have fallen short, especially on the more obscure (read: non-US) time zones.
All in all, the Java folks felt it better at the time, to provide their own verified and uniform timezone functionality. Of course, there has been a sudden flurry of DST rule changes recently, so this has caused a bump..
# 10
I noticed another forum msg/thread mentioned:1.3.1_19 works as desribed under Windows XP, but it doesn't work for Windows 2000! I'm puzzled as to why it is platform dependent!I was running my test on Win2000. I'll give Win 2003 a try and report back.
# 11
Thanks Shankar - that makes sense, you are right had they designed in an an OS specific maner, it would still leave a dependency on the OS and if teh OS changed the naming scheme etc. for the timezone, it would have required a JDK patch.Still I believe there would have been fewer JDK patches required as a result of OS changing its implementation versus the Timezone changes legislated by different governments around the world. -- Thanks for the insights.
Regards
Rajeev Bhogal
# 12
> > Question is why can Java not leverage of the DST
> > rules from theOS and why does it manage it itself.
>
>
> Surprisingly, part of the answer is that different
> OSes use different timezone names for the same
> timezones. Some use the modern "America/Los_Angeles"
> style names, while some still use names like "PST"
> and "PDT" (or "PST8PDT"). Some (esp embedded) OSes
> don't even have a time zone concept.
>
> For Java to provide a uniform interface with uniform
> names, they have to provide their own TimeZone
> library. I suppose they *could* have made the
> implementations on Windows, Linux, Solaris, etc.,
> default to the OS implementations with a [long] array
> of name mappings from Java to OS names, but this gets
> tedious to implement and verify.
>
> It also means depending on the OS to implement the
> timezones correctly, and historically, many have
> fallen short, especially on the more obscure (read:
> non-US) time zones.
>
> All in all, the Java folks felt it better at the
> time, to provide their own verified and uniform
> timezone functionality. Of course, there has been a
> sudden flurry of DST rule changes recently, so this
> has caused a bump..
It is way more than that.
From http://en.wikipedia.org/wiki/Daylight_saving_time#Computing
-
Unix systems (including Linux and Mac OS X) typically use the zoneinfo utility which allows a single time zone to have multiple DST rules to handle changes from year to year. As soon as a rule change is announced, it can be safely added to the system. All the standard library routines which calculate times access this database, so software that queries whether a particular date will have DST in effect (for the time zone of the process) will get the correct answers as long as the time zone rule is correct for the year in question.
The time zone database in most Windows-based computer systems stores only a single start and end rule for each zone, and daylight saving information is stored in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\, under the TZI registry value. (In Windows XP and Windows 2003, time-zone information is stored in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\). For example, DST ends on the last Sunday in October, regardless of year. When the rule changes (e.g. Australian DST ending one week later than usual in 2006, or DST being extended in the United States starting in 2007), an update needs to be applied. In the case of a single-year anomaly, a new time zone is created and used. Before the following year, the time zone will have to be switched back to the original. For permanent rule changes, the rule definition for the time zone can be changed without requiring a new time zone to be set up.
One of the problems of this approach is that software that uses time zone information will get incorrect results if referring to a year with rules that are different from those currently in the database. A good example is the Lotus Notes calendar system, which stores event times in UTC. Events created with calendar dates near DST start and end dates can have their local time interpretation changed after the time zone database is updated (i.e. after an operating system update is applied). Another issue was highlighted when the Australian government changed daylight saving time to end on April 2 instead of March 26, because of the 2006 Commonwealth Games. Microsoft did not modify the start and end rule for the time zones affected, but instead added new timezones with the words "(Commonwealth Games)"[12][13] which caused various issues with many software applications, including Microsoft Outlook[14] and several accounting packages. Workarounds for the issue were to use the Microsoft utility timezone to modify the start and finish of each affected timezone, then either reboot the computer or go into "Date and Time" in the Control Panel, click on the "Time Zone" tab and click on "OK" to force Windows to refresh its daylight saving time information...
-
As you can see Microsoft Windows and Unix do timezones completely different. Java adopted the Unix way of doing timezones. There is no way these two methods could have be reconciled. I personally would have hated it, if Java had adopted Microsoft's way of doing timezones.
# 13
Hi Mukesh,
I'm having the same issue on my end. Can you tell me what you did to resolve this. I'm afraid I know next to zero about Java and JRE's.
Thanks,
-Steph
> Hey
>
> I am also suffered with the same problem ,I have
> jdk142_05 version but when I am trying to update it
> then I getting the same error:-
>
> Exception in thread "main"
> java.lang.UnsupportedClassVersionError:
> com/sun/tools/tzupdater/TimezoneUpdater (Unsupported
> major.minor version 48.0)
> at java.lang.ClassLoader.defineClass0(Native
> Method)
> at
> java.lang.ClassLoader.defineClass(ClassLoader.java:703
> )
> at
> java.security.SecureClassLoader.defineClass(SecureClas
> sLoader.java:133)
> at
> java.net.URLClassLoader.defineClass(URLClassLoader.jav
> a:320)
> at
> java.net.URLClassLoader.access$400(URLClassLoader.java
> :93)
> at
> java.net.URLClassLoader$ClassFinder.run(URLClassLoader
> .java:678)
> at
> java.security.AccessController.doPrivileged(Native
> Method)
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:
> 239)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:516)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.ja
> va:460)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:448
>
>
> Did anyone have solution?
>
> Thanks in advance
> Mukesh Neg
# 14
steph Sorry!! still i don't have any solution.
# 15
hey now i am getting below error
find /u003/wls8/bea/jdk142_05 -fstype nfs -prune -o -fstype autofs -prune -o -name java -print -exec {} -jar /u003/wls8/bea/tzupdater.jar -u \;
/u003/wls8/bea/jdk142_05/bin/java
/u003/wls8/bea/jdk142_05/jre/bin/java
You have the same version as the embedded one.Anyone have idea on this?
# 16
Could you please provide details on setting the classpath variable. I appended the path of the tzupdater.jar file, but got the same error:
"Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/tools
/tzupdater/TimezoneUpdater (Unsupported major.minor version 48.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)"
Thanks,
Dan
# 17
Hi Dan,
In Windows 2000, I was able to get the command
java -jar C:\temp\tzupdater.jar -u
to work after doing the following:
1. I set classpath as an environment variable and had the following as its value: C:\temp\tzupdater.jar
2. I did notice that in the Path environment variable I had other versions of the java\bin, such as C:\Program Files\Oracle\jre\1.3.1\bin. Before I removed that value, I would get the same error: (Unsupported major.minor version 48.0). After I removed that value, and ran the tzupdater command, it ran fine. I was testing with J2SDK 1.4.2_06.
So it looks like one possibility that the error is generated is that the java.exe being used is not the right version if there are multiple versions of java on the machine.
One word of caution, in my case the removal of C:\Program Files\Oracle\jre\1.3.1\bin from the Path variable may have broken other applications. So if it turns out to be the case that you need to remove other java\bin entries from the Path variable, do a thorough testing of other applications.
Tom
# 18
Tom_Chen,THANKS! That worked!Dan
# 19
Hi,Does anyone has any experience in patching jre1.3.1_01 for the DST? Understand 1.3.1_19 has the new dst rules applied, but what those version in the range of jre1.3.1_xx (01 - 17)?PL
7e0a at 2007-7-21 16:19:44 >
# 20
Hi Leena-Could you let me know the changes that you made in the classpath for JRE after which you were able to run the tzupdater jar file.Your inputs are greatly appreciated.Thanks.Sandeep.
# 21
Hi Tom -I have verified that no java /bin is in my environment variable , but still the error persists...what could be the reason ?Thanks.Sandeep
# 22
7e0, You should consider upgrading to 1.3.1_18 for 1.3.1 US DST compliant JREs. See http://java.sun.com/developer/technicalArticles/Intl/USDST_Faq.htmlp.s 1.3.1 is now EOL'ed (End of life). Consider moving to 1.4.2 or greater.Message was edited by: coffeys
# 23
Hi Sandeep,Please verify that you have the right version of java that will work with the tzupdater, for example 1.4.X by running "java -showversion". This will show you the version of java.exe that's running.Tom
# 24
I have the same issue anyone come up with anything?
When I try to run the tool on this JRE version 1.4.2_12 I get this error:
Exception in thread "main" java.util.zip.ZipException: The system cannot find th
e file specified
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
When I try to run the tool on this JRE version 1.4.1 I get this error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/tools
/tzupdater/TimezoneUpdater (Unsupported major.minor version 48.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Any help would be appreciated because we are getting close to deadline on this.
Update- Will try setting tzupdater in temp path and see if that works like stated above. Also for removal of the Path variable do I need to reboot after?
# 25
Ok I think it worked but how can I confirm. I did not get any successfully completed confirmation? It did not give me an error this time though. Also does this only update the default JRE on the system?
# 26
> sorry for the confusion. Once the classpath was set> properly it worked fineI'm having the same problem. Can you tell me how to set up the "classpath" ? I've tried a couple hundered different ways, with no luck, I'm a sys admin without any java experience.
# 27
updating is quite simple : Use full paths is all parameters if in doubt..e.gc:\j2sdk1.4.2_12\bin\java -jar c:\tmp\tzupdater.jar -hif you still see problems..c:\j2sdk1.4.2_12\bin\java -classpath c:\tmp\tzupdater.jar -jar c:\tmp\tzupdater.jar -h
# 28
Please let me know what is the value for classpath variable to set.
