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
