I spoke too quickly :-(
When creating the 1.2.1 release, I realised that the change we have made
could have serious negative impact to some users.
The problem breaks down into two parts:
1) The toXxx() methods on DateTime/MutableDateTime.
These have a time zone to start with, and so should undoubtably retain
it. This is a bug.
2) The toXxx() methods on Instant.
Instant does have a time zone (as pointed out below) but this is really
an artifact of implementing the interface. In practice, Instant should
be thought of as having no time zone.
If an existing user has used the Instant class (and we must presume a
fair number have), then changing the behaviour of toDateTime() is a big
deal. Instead of going to the default time zone it will go to UTC. This
will break code and those users will have a right to complain.
There is no pretty solution to this. It is really a design issue where
Instant should not have any reference to a time zone.
For now, all I can see us doing is as follows:
- Change AbstractInstant to retain the time zone (ie. as per CVS)
- Change Instant to retain existing behaviour.
This will need very clear javadoc.
Stephen
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
