Here is the gist of the problem :

1. You need Java 1.4.2.11 or Java 1.5.0.6 to get the new zone files.
2. If you are using NSTimestamp, you need to not use it for timezone stuff. WO still uses NSTimezone when you pass in a Java TimeZone, and uses its own zone files, which are hopelessly out of date.

In our case, we store everything in the db as GMT, and then convert on the fly depending on what zone the user is in. We use the following methods :

        /**
         * Returns a new time stamp for the passed in Timezone.
         *
         * @param iMillis time stamp to be converted
         * @param iZone Timzone in which conversion is needed.
         * @return an NSTimestamp with date converted to iZone.
         */
public static NSTimestamp changeDateForTimezone(long iMillis, TimeZone iZone) {
                long anOffset = 0l;
                if (iZone != null)
                        anOffset = iZone.getOffset(iMillis);
                return new NSTimestamp(iMillis + anOffset);
        }       
public static NSTimestamp changeDateForTimezone(NSTimestamp iTimestamp, TimeZone iZone) {
                return changeDateForTimezone(iTimestamp.getTime(), iZone);
        }       


Hope this helps.



On Dec 19, 2006, at 7:06 PM, Dan Faber wrote:


I notice the sun tool says:
 The java.vendor property value must be "Sun Microsystems Inc.".
so I bet it won't work for Apple JVMs. It didn't appear that Apple
had a JVM release that met the dates shown on the sun page. Maybe
we are stuck?


Thanks to all for the VERY timely replies to my problem. Art is correct that compiled timezone files are kept in /System/Library/ Frameworks/
JavaVM.framework/Versions/1.5.0/Home/lib/zi.

Apparently the file for my area "Denver" has been fixed in a newer version of the apple java. I downloaded that version and copied the "Denver" file from the zi directory into my 1.5.0 zi directory. Now the problem is gone (so far) on the development system, but still does not work correctly on the deployment system :(

Still searching for a reason...

Thanks to all,

Dan Faber


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/ddenboer% 40apple.com

This email sent to [EMAIL PROTECTED]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to