Home

News: U.S. Daylight Savings Changes in 2007

  1. U.S. Daylight Savings Changes in 2007 (29 messages)

    Sun's Developer Network has posted "U.S. Daylight Saving Time Changes in 2007," detailing the changes in the start and end dates of daylight savings. This affects the JVM because it compensates for DST in various countries and older JVMs' information about DST is incorrect. Downloading a current JVM, meaning the JSE6 beta, 1.5.0_06 or later, and 1.4.2_11 or later, corrects the problem. However, note that this may imply a regression test of applications just in case the newer JVMs introduce incompatibilities; also note that Sun does not suggest anything older than 1.4.2_11, which may affect users still on 1.3 or older.

    Threaded Messages (29)

  2. Is there any solution for JDK1.3 and older?. How we are going to solve old applications?.. Ravi
  3. Ravi, You can run old applications on a new JVM (and should do so, if only for the performance improvements). The JVM knows from the .class file what compatability mode to run with. Even Java 1.0 applications should run in a Java 5 or Mustang JVM just fine.
  4. Thanks. Do we need to upgrade our JRE/JDK ?.What about JDK1.3 specific functinalities like... Timestamp.getTime() method... Ravi
  5. OC4J does not the later JDK.[ Go to top ]

    I used to work for the now biggest wireless company. The OC4J from Oracle is compatible with JDK 1.3.1, but it won't run under JDK 1.4.*. It generates some thing like "JVM version is too new" errors.
  6. I assume that since the list doesn't simply say 1.4.2 or later, changes to the DST dates are bundled with the JVM? If so, does anyone know if there some reason this shouldn't be made configurable so that enterprises aren't forced both to monitor DST changes for impact and then absorb JVM migration expenses?
  7. Costs of DST changes[ Go to top ]

    I assume that since the list doesn't simply say 1.4.2 or later, changes to the DST dates are bundled with the JVM?

    If so, does anyone know if there some reason this shouldn't be made configurable so that enterprises aren't forced both to monitor DST changes for impact and then absorb JVM migration expenses?
    Well, one solution would be to simply set your servers to not adjust for DST all. Since the JVM gets time and timezone information directly from the system it is running on, this would actually eliminate the need to worry about it. Actually, always running your servers in UTC (GMT) makes a lot of sense. Having said that, I'm not sure why the JVM would need any rules pertaining to the DST observances if that information is garnered from the host OS. Did Sun release JVM updates when (parts of) Indiana decided to observe DST this year? As far as absorbing expenses due to these changes, take it up with your elected officials.
  8. Reason to care[ Go to top ]

    If you are writing an application that needs to do date calculations for other locales other than the default locale of the server, even running in GMT time will affect these calculations.
  9. DST rules in Java[ Go to top ]

    I assume that since the list doesn't simply say 1.4.2 or later, changes to the DST dates are bundled with the JVM? If so, does anyone know if there some reason this shouldn't be made configurable so that enterprises aren't forced both to monitor DST changes for impact and then absorb JVM migration expenses?
    Sun has always taken the approach of updating the DST rules whenever it releases a JDK patch release.
    Well, one solution would be to simply set your servers to not adjust for DST all. Since the JVM gets time and timezone information directly from the system it is running on....
    Er, no. The JDK determines which time zone *ID* its running on from the operating system, but the rules for when DST starts and stops are encoded in the JDK. Basically, all the zone information is derived from the Olson zone database - http://www.twinsun.com/tz/tz-link.htm - which monitors and records it in a text file. Every JDK patch release picks up a snapshot of the Olson data and encodes it to a binary format. There is then no way to update that data (en masse) other than updating to a later JDK patch version. As indicated in the article, because JDK1.0 to 1.3 are end of life, the time zone data for these systems will not be updated by Sun. There are three main solutions: a) Upgrade to JDK1.4 or 1.5. Simplest solution for many, unless you are limited by an app server dinosaur like WebSphere. b) Create and use your own implementation of SimpleTimeZone passing in the new rules in the constructor. c) Use Joda-Time, which allows the latest Olson time zone rules to be updated at any time. Disclaimer - I'm project lead on Joda-Time. By the way, Brazil changes its DST rules practically every year, so relying on hard coded data in the JDK is pretty risky. Stephen Colebourne Joda-Time - http://joda-time.sourceforge.net
  10. At least you don't have to make actual code changes. :)
  11. OpenSource (OpenHardware)[ Go to top ]

    My Vote is 50-50 for OpenSource and Commercial, both have their own advantages and disadvantages. When will there be Open Hardware Market :)
  12. What if there is again DST changes
  13. I have used variable for Enumeration as enum every where in the code i shipped to the client. Now that enum is a keywork in 1.5, will that still works?? Vijay
  14. Does anyone have any suggestion for the Daylight saving change in 2007 in the context of Oracle's JDeveloper/9iAS? Our system uses Oracle 9iAS's JDK for the time zone and daylight saving adjustment which comes from Sun. So the patch does nothing for us. Now the Sun JDK 1.3.1_19 supposedly have the fix, but our JDeveloper doesn't like it because it says it's certified only for JDK 1.3.1_02. There is a documentation on how to have JDev use other JDK versions (http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/locale.en/navId.4/navSetId._/vtTopicFile.java_app_dev%7Cbuild%7Ccom_p_jdk14support~html/) but that's for 10g and I don't have the said batch file in my directory. I have JDeveloper 9.0.3.1035, 9iAS 9.0.3, Sun JDK 1.3.1_02. Can someone tell me how I can use Sun JDK 1.3.1_19? Or perhaps suggestion on a different approach - without having to go into Oracle 10g. We need the Calendar java class for time zone and and daylight savings functions. TIA!
  15. Easy, use Joda-Time[ Go to top ]

    I'm a firm believer in using Joda-Time for applications that deal with dates. It's far less invasive to update a library than a JVM, plus it has the advantage of being more pleasant to work with from an API perspective.
  16. Re: Easy, use Joda-Time[ Go to top ]

    ...plus it has the advantage of being more pleasant to work with from an API perspective.
    Is it possible to be less pleasent?
  17. Websphere customers[ Go to top ]

    http://www-1.ibm.com/support/docview.wss?uid=swg21219396
  18. Re: Websphere customers[ Go to top ]

    http://www-1.ibm.com/support/docview.wss?uid=swg21219396
    It talks about IBM WebSphere Application Server. But what about IBM WebSphere Application Client? Do we need to apply this utility separately for the client? Does this utility have option to select client or server?
  19. all congress' fault[ Go to top ]

    if back in 2003 you made a statement about 'Mar 31 00:00 2007 PDT', now what time exactly did you mean? if you have persisted that time in one format or the other, do you need to migrate it? there are no easy answers to those questions, a time is no longer a sure thing, it depends on the time a time is mentioned, and the intention of the person mentioning it.
  20. Pain in the neck![ Go to top ]

    Am I the only one who thinks that it is high time these variations to daylight saving time be wound back a bit (i.e. someone with an IT background slapped some sense into politicians). For instance in Australia recently they changed the time to fit the commonwealth games. Hardly a necessary or critical reason to force us all to roll out unix/java patches across thousands of servers. Not to mention the associated meetings, after hours time in lieu, hosting centre support costs. I'd love to know how much the total cost across the affected IT industry is each time someone decides they want a few weeks one way or the other for basically political or event related reasons (rather than to keep the sun up and down times roughly in line with the clock times). Still, you could go the other end of the scale like China and just have one timezone and no daylight savings despite the country really needing 3 or so timezones (so from korean border to nepal all at GMT+8 or whatever it is). regards, Nathan Lee
  21. A Solution[ Go to top ]

    Hi! For version 1.4.x 1.5.x you *don't* have to upgrade your jdk/jre version in use. Just update the relevant zoneinfo binary files, located at: /lib/zi/* e.g. Israel (like Brasil) DST rules changes every year, So we should update the file: "/lib/zi/Asia/Jerusalem" with the Jerusalem file from the newest JAVA distribution (currently 1.5.0_08) The fact that the JRE doesn't use the host's OS DST rules is a bad design and causes managers to dislike "THOSE JAVA APP SERVERS". Gili Nachum.
  22. I recently published a more detailed description of the problem and its workarounds. have a look at this javaworld article: http://www.javaworld.com/javaworld/jw-12-2006/jw-1201-dst.html
  23. JDK 1.3.1_19 upgrade[ Go to top ]

    Jim and Gili, thanks much for your very informative posts. I had thought 1.3.1_19 plain doesn't work, not realizing that it works if I set the local time to sometime next year (2007). So that's at least one more option at my disposal. I surely hope Sun has a real fix on 1.3.1. 1.4.2_13 works in general if I just replace the 1.3.1_02 with it. But I get "Native VM not supported" error when I use utilities such as "imp"... I wouldn't be surprised if there are errors popping up else where. So for now I'm nervous about using it. BTW, what is the proper way to "upgrade" the JDK? Do I simply replace the JDK directory of the old with the new? On Oracle I seem to lose Oracle's native VM somewhere along the way if I just replace the directory. David
  24. Re: JDK 1.3.1_19 upgrade[ Go to top ]

    Hi David, I think the proper way to "upgrade" the Sun JDK depends on the program using it. For instance, we are using primarily from WebLogic, a stand alone Java server program, and Java Web Start. In the first two cases, it's a matter of installing the new JDK alongside the old (the default path usually places it in a version-specific directory) and changing startup shell scripts to use the new path. We have Linux systems, and I have been using Sun's RPMs to install the JDKs so far. The RPMs up through 1.3.1_15 are not mutually exclusive and do not try to uninstall older versions. In the case of Java Web Start (this is the older pre-1.4 Java Web Start), it's a matter of changing our launch file to specify the newer version and then going to each client and installing the new JRE (alongside the old one, again) and configuring it in the client's Java Web Start preferences. If you need to upgrade the JVM inside Oracle, I think that would be a whole different procedure, involving running Oracle patches that update their JVM files. If you're running non-Oracle Java programs on your Oracle host machine, and want to use the Sun JDK for them, I think you'd just have to install the JDK in its default path, for use alongside the Oracle versions without replacing them.
  25. Re: JDK 1.3.1_19 upgrade[ Go to top ]

    Jim, thanks! I'm using Oracle 9iAS, so I think I might be lacking a corresponding patch from Oracle for the 1.3.1_19. I'll hopefully find out from the Oracle forum.
  26. Re: JDK 1.3.1_19 upgrade[ Go to top ]

    Here's some more details we found on Oracle's Metalink site about Oracle's handling the JVM issue: Oracle's Note 359145.1 ("Impact of 2007 USA daylight saving changes on the Oracle database") addresses this subject, and does refer to JVM issues ("JVM Fixes"). The note recommends installing a patch containing an update to the core Java classes, including patch no. 5047902 for Oracle 9.2.0.7.0. If you read that patch's README instructions, the patch apparently updates a native-code shared object that implements the core Java classes for Oracle.
  27. Re: JDK 1.3.1_19 upgrade[ Go to top ]

    Thanks Jim. Runtime is OK under Oracle's Apps Server, but warning messages under JDeveloper. But it's just annoyance for now. For anyone who has experience with joda-time, do I download 1.3 for my 1.3 JDK and 1.4 for 1.4 JDK? TIA. I assume both versions have the 2007 DST fixes.
  28. Re: JDK 1.3.1_19 upgrade[ Go to top ]

    JDK 1.3.1_19 works on Windows XP, but NOT Windows 2000. Anyone experience the same? Any workarounds?
  29. Egypt, Syria, Uruguay[ Go to top ]

    As an example of how little notice developers have of change, Due to Ramadan: - Syria will change on 21st September 2006 (instead of 1st October normally) - Egypt will change on 25st September 2006 (instead of the last Thursday in September normally) and Uruguay will change on first Sunday in October 2006 So, be very careful when relying on the JDK for tz data. Stephen Colebourne Joda-Time - http://joda-time.sourceforge.net
  30. The Sun Java article mentioned in the original message above refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5. Sun did make changes to 1.3 for the new time zone daylight data. But it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone. I ran tests on the latest 1.3, 1.4, 1.5 JDKs and looked at time zone source code for 1.3... JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle US 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates. JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly. Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3. What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application. If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround? If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds: 1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible. 2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones. Related Sun Java Bug Database bugs: * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1. * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1. * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates. Sun Java Forum topic I posted about 1.3 and the daylight change: http://forum.java.sun.com/thread.jspa?threadID=790266 Thanks for any info or advice available, Jim