RE: Time zones are driving me CRAZY
RE: Time zones are driving me CRAZY
- Subject: RE: Time zones are driving me CRAZY
- From: "Pierre Bernard" <email@hidden>
- Date: Fri, 21 Nov 2003 11:25:34 +0100
- Thread-topic: Time zones are driving me CRAZY
Hi Mankit !
Thanks a bunch for your help. Are you with the WebObjects team?
Based on the information you provided that Sun's implementation returns differing results in JDK 1.3 and JDK 1.4 I have done further research.
It appears that, with Java 1.4, Sun has corrected a longstanding bug with timezones and date computations. Until then Java applied the time zone rules valid in the year 2000 to dates in any period of time. That is past exceptions or changes to offset, DST etc. were not considered.
Starting with version 1.4 Java behaves according to the widely published Olson timezone data. Among the many changes the "Europe/Luxembourg" timezone has undergone, one can see from this data that up until June 1904 we had a GMT offset of 0:24:36 compared to the 1:00:00 offset we have now. This accounts for the divergence observed in my test case.
While it is indeed the JDK implementation - not NSTimestampFormatter - that has changed, it appears to have changes for the better. This ought to be a sufficient reason for Apple to follow the lead. Moreover not adapting NSTimestampFormatter to the behavior observed in JDK 1.4 introduced incompatibilities between the parsed NSTimestamps & Sun's implementation of GregorianCalendar. Extracting fields from the NSTimestamp using GregorianCalendar as recommended by the NSTimestamp documentation produces unexcpected results. This causes us major grief.
More information on the change can be found at the following locations:
- BugParade on java.sun.com: #4257314, #4505478
- Core Library Changes: http://java.sun.com/j2se/1.4/jcp/j2se-1_4-mr_docs-spec/core-libraries.html
Best,
Pierre Bernard
--
Got a hang for movies?
http://homepage.mac.com/I_love_my/movies.html
-----Original Message-----
From: Mankit Sze [mailto:email@hidden]
Sent: Thursday, November 20, 2003 8:44 PM
To: Pierre Bernard
Cc: email@hidden
Subject: Re: Time zones are driving me CRAZY
Importance: High
On Nov 20, 2003, at 1:35 AM, Pierre Bernard wrote:
> Product: WebObjects 5.2.2
> Subject: Inconsistent behavior of NSTimestamp & NSTimezone
>
>
> Hi!
>
> Since upgarding our Windows 2000 development machines to WebObejects
> 5.2.2 running on Sun's J2SE SDK 1.4.1_05, we are observing a series of
> problems with both NSTimestamp and NSTimeZone. This causes us major
> trouble and has basically stalled development on our current project.
> As it stands we can no longer trust parsing, display nor computation
> involving NSTimestamp.
> Below I have detailed a few examples which seem to reveal problems
> with NSTimestampFormatter and NSTimeZone. I can only hope this is the
> single source of all problems. Yet it may just as well be another
> manifestation of the root problem that causes all oddities observed.
> Or, worse, it could be just one of many more problems with timestamps.
>
> The examples below were exectued in the main method of a vanilla
> WOApplication. They were run on a Windows 2000 PC using Java 1.4.1_05.
> The same examples produced slightly different errors in short test on
> a Mac OS 10.3 machine with the lates Java update.
>
> Example 1: Parsing the date "190101" in the "Europe/Luxembourg" time
> zone
>
> NSTimeZone.setDefault(NSTimeZone.getTimeZone("Europe/Luxembourg"));
> TimeZone.setDefault(TimeZone.getTimeZone("Europe/Luxembourg"));
>
> String dateString = "190101";
> NSTimestampFormatter nsFormatter = new
> NSTimestampFormatter("yyyyMM");
> SimpleDateFormat sdFormat = new SimpleDateFormat("yyyyMM",
> Locale.US);
>
> NSTimestamp date1 = (NSTimestamp)
> nsFormatter.parseObject(dateString);
> Date date2 = sdFormat.parse(dateString);
>
> System.out.println(date1.getTime());
> System.out.println(date2.getTime());
>
> System.out.println(date1.getTime() == date2.getTime());
> The above code is parsing the very same date string once using
> NSTimestampFormatter and once using SimpleDateFormat. This produces
> two date objects. One java.util.Date and on NSTimestamp, a subclass of
> Date. Both dates should represent the same point in time. To check
> this their internal represenation - milliseconds since a reference
> date - are compared.
>
> -2177456400000
> -2177454276000
> false
>
> One would expect the results to be the same, yet they are not. There
> is an offset of 2124 seconds.
Running your test case on Java Virtual Machine Ver. 1.3.1 + WebObjects
5.2., I got the following result:
Java Virtual Machine Ver. 1.3.1
-2177456400000<-- from NSTimestampFormatter
-2177456400000<-- from SimpleDateFormat
true
Running your test case on Java Virtual Machine ver. 1.4.1 + WebObjects
5.2.2, I got these outputs:
Java Virtual Machine Ver. 1.4.1_01
-2177456400000<-- from NSTimestampFormatter
-2177454276000<-- from SimpleDateFormat
false
Attached below is a slighly modified version of your test case you
could use to verify the result I produced above.
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender
of this message. (email@hidden)
This email message has been checked for the presence of computer
viruses; however this protection does not ensure this message is
virus free.
Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu
**********************************************************************
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.