I am not sure if I can follow your argumentation. Yes, the internal milli
seconds of the returned Date is the same as the milli seconds contained in the
returning DateTime object. But this does not change the fact, that the
returned Date object is defacto a different date than what the DateTime object
represents. And correct me if I am wrong, all boils down to the usage of
millisecond, doesn't it?
If I construct the Date object using Calendar and setting each field explicitly
as done below, then I get the correct Date object and the milliseconds are
quite different.
DateTime: -15059664422000
Date: -15058886386000 // constructed using Calendar
public static void main(String[] args) {
DateTimeFormatter fmt = DateTimeFormat.forPattern("MM/dd/yyyy");
DateTime dateTime = fmt.parseDateTime("10/11/1492");
DateTime gjcDateTime = new DateTime(dateTime.getMillis(),
GJChronology.getInstance());
System.out.println("dateTime: " + dateTime);
// prints: dateTime: 1492-10-11T00:00:00.000-07:52:58
System.out.println("dateTime.getMillis(): " + dateTime.getMillis());
// prints: dateTime.getMillis(): -15059664422000
System.out.println("dateTime.toDate().getTime(): "
+ dateTime.toDate().getTime());
// prints: dateTime.toDate().getTime(): -15059664422000
System.out.println("dateTime: " + dateTime.toDate());
// prints: dateTime: Mon Oct 01 23:52:58 PST 1492
System.out.println("gjcDateTime: " + gjcDateTime.toDate());
// prints: gjcDateTime: Mon Oct 01 23:52:58 PST 1492
// prints Mon Oct 01 23:52:58 PST 1492
Calendar jdkCal = dateTime.toGregorianCalendar();
System.out.println("jdkCal: " + jdkCal.getTime().toString());
// prints: jdkCal: Mon Oct 01 23:52:58 PST 1492
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, dateTime.getYear());
cal.set(Calendar.MONTH, dateTime.getMonthOfYear() - 1);
cal.set(Calendar.DATE, dateTime.getDayOfMonth());
cal.set(Calendar.HOUR, dateTime.getHourOfDay());
cal.set(Calendar.MINUTE, dateTime.getMinuteOfDay());
cal.set(Calendar.MILLISECOND, dateTime.getMillisOfSecond());
System.out.println("cal.getTime().toString(): " +
cal.getTime().toString());
// prints: cal.getTime().toString(): Thu Oct 11 00:00:34 PST 1492
System.out.println("cal.getTime().getTime(): " +
cal.getTime().getTime());
// prints: cal.getTime().getTime(): -15058886386000
}
-----Original Message-----
From: Brian S O'Neill [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2008 9:29 AM
To: Discussion of the Joda project
Subject: Re: [Joda-interest] Problem with DateTime toDate - java.util.Date
returns different date
After calling toDate, the actual instant in time that it represents is
preserved. What you are seeing is just a different interpretation of how
it should be presented. If you construct a DateTime again from the Date,
you should see that it is the same as it was before. The underlying
instant in both DateTime and Date is the number of milliseconds elapsed
from 1970-01-01T00:00.00.000Z. The values returned by
DateTime.getMillis() and Date.getTime() will be the same.
Andreas Guther wrote:
>
> Brian,
>
> Thank you for your explanation. I will try to solve the problem using
> the GJChronology.
>
> In general I feel that my expectation is mislead by providing a toDate
> method that returns a java.util.Date object that contains a different
> date than the DateTime object.
>
> I could also not find a hint on the problematic in the Java code
> (JavaDocs). My expectation is that a method toDate returning a
> java.util.Date should be able to return the correct object. If Joday
> Time knows about the different calendars, why not internally adjust
> and correct the difference rather than move the burden to the user. Or
> not providing a toDate at all.
>
> Andreas
>
> *From:* Brian O'Neill [mailto:[EMAIL PROTECTED]
> *Sent:* Monday, November 10, 2008 5:33 PM
> *To:* Discussion of the Joda project
> *Subject:* Re: [Joda-interest] Problem with DateTime toDate -
> java.util.Date returns different date
>
> Joda-Time by default uses an ISO chronology, which is a proleptic
> gregorian calendar. Java's Date class uses a gregorian/julian calendar
> which has a gap of several days to account for the error between the
> two. If you want the two representations to be the same, you need to
> use Joda-Time's GJChronology.
>
> Other differences are caused by how the time zone rules are
> implemented. Joda-Time strictly follows the tz database rules, which
> is why you see differences before 1884.
>
> If you want to support historical datetimes in a consistent fashion,
> the easiest thing is to not switch between Joda-Time and Java Date.
>
> On Mon, Nov 10, 2008 at 4:36 PM, Andreas Guther
> <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi,
>
> I noticed a converting problem from DateTime to java.util.Date. Dates
> in the past seem to be off by one or more days, depending on how far
> those dates are in the past. My observation is, that dates until 1884
> are fine, but before are starting to be off by one day. Is there
> something I have to configure. It is hard to believe that this is a bug.
>
> public static void main(String[] args) {
>
> DateTimeFormatter fmt = DateTimeFormat.forPattern("MM/dd/yyyy");
>
> DateTime dateTime = fmt.parseDateTime("10/11/1492");
>
> System.out.println(dateTime);
>
> // prints 1492-10-11T00:00:00.000-07:52:58 - AS EXPECTED
>
> System.out.println(dateTime.toDate());
>
> // prints Mon Oct 01 23:52:58 PST 1492 - MONTH OK, BUT DAY WAY OFF!!!!
>
> }
>
> We are currently using joda-time 1.5.2. <http://1.5.2.>
>
> Andreas
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> <mailto:Joda-interest@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
