[ http://issues.apache.org/jira/browse/TUSCANY-701?page=all ]
Brian Murray updated TUSCANY-701:
---------------------------------
Attachment: Tuscany701.patch
The attached patch introduces changes into DataHelperImpl.java and
DateConversionTestCase.java. The changes to the test case are limited to
uncommenting the tests that were commented as a result of this issue, and
printing to System.err the expected and received values in the event of a
mismatch.
The changes to DataHelperImpl.java are to remove the call to
SimpleDateFormat.setLenient(false) and another described in the following
paragraph. When isLenient() is false, the IBM JVM seems unable to parse time
zones. (Or at least it is unable to parse many timezones that are recognized
when isLenient() is true - which are also recognized for isLenient() true or
false with the Sun JVM.) With isLenient() being returned to true, the
SimpleDateFormat is now built based upon the input string, rather than the
previous technique of cycling through the possibilities.
The final change included in this patch is to accomodate for lost values when
the input string passed to toDate does not include certain fields. For various
permissable input strings (e.g. those resulting from toYear, toDay, toTime),
there are fields missing which when converted to Date have default values.
(e.g. Year -> 1970). Because of this, there can be great variation in how
daylight savings time is accounted for. (e.g. In 1970 Britain was on DST year
round, and during the summer of 1944 was on double daylight time. Because
these possible variations exist, it is assumed that the user would prefer the
current handling of daylight savings time. As such, the year, month and day
will default to their current values when absent.
Possible concerns with this technique and how they are addressed:
* What if the user is checking for the default values to determine if the
value was explicitly set or defaulted?
- The user should not be checking for Year=1970 (or month=January, etc.) as
evidence of taking the default, as explicitly setting a year to 1970 is valid
and would then not be an instance of a default taken. Calling toDate on a
string with missing fields (e.g. 01:05:04 EST) will require defaults because
Date is stored only as a long value indicating time since the Epoch.
Defaulting to current values instead of the Epoch for these fields will insure
that current DST rules are in place for the fields that are of interest. As
noted in the issue description, the affected fields are not limited to time.
* If I enter a non-daylight savings time during a daylight savings month (or
vice versa) might the time be off by DST offset (because the missing parts of
the date are set to when the method is being executed - possibly eliminating
the proper handling of the DST).
- No. Here is a sample program and the resulting output. This test was run
on both the IBM and Sun JVMs - as well as in both summer and winter months.
public void testTimeZoneWithDefaults()
{
System.out.println(data_helper.toDate("04:20:00 EST"));
System.out.println(data_helper.toDate("04:21:00 EDT"));
}
Results running in the summer:
Thu Sep 14 05:20:00 EDT 2006 <-- = 4:20 EST
Thu Sep 14 04:21:00 EDT 2006
Results running in the winter:
Tue Feb 14 04:20:00 EST 2006
Tue Feb 14 03:21:00 EST 2006 <-- =4:21 EDT
> Conversion to date types which do not include month can give incorrect results
> ------------------------------------------------------------------------------
>
> Key: TUSCANY-701
> URL: http://issues.apache.org/jira/browse/TUSCANY-701
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Environment: Problem exists when running Sun JVM (is not seen on IBM
> JVM)
> Reporter: Brian Murray
> Priority: Minor
> Attachments: Tuscany701.patch
>
>
> DateConversionTestCase.java made evident an issue corrected in Tuscany-582.
> However, when it was introduced into the Tuscany stream an additional error
> was seen sporadically (repeatedly for a given individual, but for a set of
> individuals only a subset would see the problem). This JIRA will address the
> additional error.
> The reason the problem is seen only by a subset of people is that it is JVM
> specific. When it is seen (as it is with the Sun JVM), the nature of the
> problem is to report Day, Hour, and even Year values as X - 1, where X is the
> correct value. The problem occurs when the requested date format does not
> include a month (e.g. toYear, toDay). The truncated month is assigned a
> value of January, and the Sun JVM may then (depending on the TimeZone,
> northern versus southern hemisphere, and the month in which the test is run)
> change the time to reflect the change to or from daylight savings time.
> The reason it can have an impact on toYear is that toYear() for an input date
> of Wednesday September 6, 2006 03:16:20.382 would result in an interim value
> of Sunday January 1, 2006 00:00:00.000. In the case where an error is seen,
> an adjustment is made for daylight savings time to Saturday December 31, 2005
> 23:00:00.000. As such, toYear erroneously returns a value of 2005 for the
> input date (in the error case).
> Would a committer please assign this issue to me?.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
