We weren't sure it was a bug or behavior change, but it did break our
code several weeks ago, and we had to implement a workaround.
IMHO, it warrants a patch release.
-phil
Stephen Colebourne wrote:
>Based on this evaluation, I'd say it was a bad bug and should be fixed.
>
>The toXxx() methods should not lose the zone.
>
>Stephen
>
>
>Quoting Brian S O'Neill <[EMAIL PROTECTED]>:
>
>
>>I say this is a bug. When I "fix" it, some of the unit tests complain,
>>however.
>>
>>The current implementations of toDateTime(), toDateTimeISO(),
>>toMutableDateTime(), and toMutableDateTimeISO() are all wrong. They all
>>discard the time zone.
>>
>>I think this bug resulted from all the changes that took place before
>>v1.0 with respect to the Instant class -- should it have a time zone or
>>not. The conversion methods are all in the AbstractInstant class, and
>>their behavior is correct for an Instant which lacks a time zone of its
>>own. Since they now do have a time zone (UTC), it makes sense to ensure
>>that the common implementations preserve the time zone.
>>
>>I'm not going to make any changes until Stephen has had a chance to look
>>things over.
>>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>>I'm not sure if this is a bug or the way it's suppose to work, so
>>>please let me know after I let everyone know the scenario:
>>>
>>>I have a DateTime object that has a timezone different than the
>>>default VM timezone. For example, the default VM timezone is
>>>'America/New_York' and the DateTime object I have is UTC. When I get
>>>a MutableDateTime object from the UTC DateTime object reference, it
>>>loses the UTC timezone and returns a MutableDateTime with the
>>>'America/New_York' timezone. At the same time, the date/time has been
>>>changed to reflect the 'America/New_York' TZ offset. In looking at
>>>the javadoc I see there is a DateTime.toMutableDateTime(DateTimeZone
>>>zone) method, but I assumed this should be called if you want the TZ
>>>of the DateTimeMutable to be different than the DateTime object it's
>>>being constructed from.
>>>
>>>Shouldn't the TimeZone of the DateTime object be used as the 'default'
>>>when creating a MutableDateTime object from it's 'toMutableDateTime()'
>>>method?
>>>
>>>Here is an example:
>>> DateTime dt = *new* DateTime(DateTimeZone.UTC);
>>> System.out.println("dt: "+dt);
>>> MutableDateTime mdt = dt.toMutableDateTime();
>>> System.out.println("mdt: " +mdt);
>>> MutableDateTime mdt2 = dt.toMutableDateTime(dt.getZone());
>>> System.out.println("mdt2: " +mdt2);
>>>
>>>Output:
>>> dt: 2006-02-08T15:46:02.620Z
>>> mdt: 2006-02-08T10:46:02.620-05:00
>>> mdt2: 2006-02-08T15:46:02.620Z
>>>
>>>Notice the difference between 'mdt' and 'mdt2'. 'mdt2' is the same as
>>>the 'dt', whereas the 'mdt2' is 5 hours behind.
>>>
>>>The need to pass in the timezone of the object you're creating the
>>>MutableDateTime object from seems redundant and easy to introduce bugs
>>>in your logic.
>>>
>>>
>>>FYI: I am using the latest Joda 1.2 library.
>>>
>>>
>>>Any insight or feedback would be greatly appreciated.
>>>- Aaron
>>>
>>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>>_______________________________________________
>>Joda-interest mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>>
>>
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Joda-interest mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest
