|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 29
Messages: 29
Messages: 29
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
U.S. Daylight Savings Changes in 2007
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.
|
|
|
Message #218052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
Is there any solution for JDK1.3 and older?. How we are going to solve old applications?..
Ravi
|
|
|
Message #218054
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
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.
|
|
|
Message #218061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
Thanks. Do we need to upgrade our JRE/JDK ?.What about JDK1.3 specific functinalities like... Timestamp.getTime() method...
Ravi
|
|
|
Message #218068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
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?
|
|
|
Message #218074
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
At least you don't have to make actual code changes. :)
|
|
|
Message #218075
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Costs of DST changes
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.
|
|
|
Message #218078
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Easy, use Joda-Time
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.
|
|
|
Message #218085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reason to care
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.
|
|
|
Message #218101
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
all congress' fault
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.
|
|
|
Message #218106
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Easy, use Joda-Time
...plus it has the advantage of being more pleasant to work with from an API perspective.
Is it possible to be less pleasent?
|
|
|
Message #218163
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DST rules in Java
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
|
|
|
Message #218191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pain in the neck!
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
|
|
|
Message #218193
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OpenSource (OpenHardware)
My Vote is 50-50 for OpenSource and Commercial, both
have their own advantages and disadvantages.
When will there be Open Hardware Market :)
|
|
|
Message #218195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: U.S. Daylight Savings Changes in 2007
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
|
|
|
Message #218210
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Solution
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:
<JRE HOME>/lib/zi/*
e.g. Israel (like Brasil) DST rules changes every year, So we should update the file:
"<JRE HOME>/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.
|
|
|
Message #218317
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Egypt, Syria, Uruguay
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
|
|
|
Message #218455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OC4J does not the later JDK.
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.
|
|
|
Message #222755
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Daylight saving change and JDK 1.3.1_02 for JDeveloper
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!
|
|
|
Message #223013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDK 1.3 time zone daylight rule support
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
|
|
|
Message #223275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JDK 1.3.1_19 upgrade
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
|
|
|
Message #223314
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JDK 1.3.1_19 upgrade
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.
|
|
|
Message #223319
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JDK 1.3.1_19 upgrade
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.
|
|
|
Message #223393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JDK 1.3.1_19 upgrade
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.
|
|
|
Message #223591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JDK 1.3.1_19 upgrade
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.
|
|
|
Message #224036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JDK 1.3.1_19 upgrade
JDK 1.3.1_19 works on Windows XP, but NOT Windows 2000. Anyone experience the same? Any workarounds?
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
