Joda Time subtracting 24 hours from an instance of MutableDateTime, I would like to know why

I do not understand why MutableDateTime.setDate() is setting the time to "yesterday" 开发者_运维技巧(see the log timestamp hours - it is 20:28). Is this timezone related? Do I need to set something on the formatter?

I would expect that after calling setDate with "10/27/2010", the date would be the same as the parsed date 00:00 EDT 10/27/10, instead of 20:28 EDT 10/26/10. This is 24 hours ago from "now".

What am I missing here, or how should I edit the code to get the desired result? I am new to Joda Time, and would like to solve this mystery.

DateTimeFormatter dateFormatterJ = DateTimeFormat.forPattern("MM/dd/yyyy");
DateTimeFormatter timestampFormatJ = DateTimeFormat.forPattern("HH:mm zzz MM/dd/yy");

MutableDateTime startDate = new MutableDateTime();

log.info("parsed date " + 
    timestampFormatJ.print(dateFormatterJ.parseMutableDateTime(startDateString)));

startDate.setDate((dateFormatterJ.parseMutableDateTime(startDateString)));

log.info("startDate: " + timestampFormatJ.print(startDate));

In this case, startDateString is simply "10/27/2010".

here is the log output:

10-27 20:28:55 INFO parsed date: 00:00 EDT 10/27/10
10-27 20:28:55 INFO startDate: 20:28 EDT 10/26/10

Thanks

---

The simple answer would be, because the javadoc says so.

public void setDate(ReadableInstant instant)

Set the date from another instant. The time part of this object will be unaffected.

Parameters: instant - an instant to copy the date from, time part ignored

Throws: IllegalArgumentException - if the object is invalidobject is invalid

When Joda says 'Date' it means the human meaning of the word Date. "The year-month-day portion of this value", not the logical equivalent of a java.util.Date. (the whole point of joda being to introduce some natural, sensible, semantics to handling date and time.)

EDIT: To answer your 'how to fix' question, simply do:

MutableDateTime startDate = new MutableDateTime(dateFormatterJ.parseMutableDateTime(startDateString));

Or else manually zero out the time portions of course.

EDIT 2: Hmm, I apparently did not read carefully enough, this is only half of the answer. Will check.

EDIT 3: well this bugged me so much that I took a minute to look for it.

public void setDate(final ReadableInstant instant) {
    long instantMillis = DateTimeUtils.getInstantMillis(instant);
    Chronology instantChrono = DateTimeUtils.getInstantChronology(instant);
    DateTimeZone zone = instantChrono.getZone();
    if (zone != null) {
        instantMillis = zone.getMillisKeepLocal(**DateTimeZone.UTC**, instantMillis);
    }
    setDate(instantMillis);
}

For some reason, it's rolling your absolute time forward into UTC before setting the date. So you give it 10/27/2010 00:00 EDT and it sets the absolute magnitude of time to the number of milliseconds that represent 10/27/2010 00:00 UTC, which of course is only 6 or 7 PM the day before. Then it finds the EDT date value of that to be 10/26.

Couldn't say if that's somehow intended or if it's a bug that's been there for 2 years or what.)

---

When parsing a string that does not contain a GMT offset or time-zone ID, you must do one of three things:

• do nothing, and accept that the string is parsed in the default time zone
• specify the time zone to parse in using withZone() on the formatter
• use parseLocalDate() instead of parseMutableDateTime()

The last is the preferred solution, as it correctly parses the data that was actually input, which was a date without time, offset or zone.

Using parseLocalDate() in the test code correctly parses the date.