#100 MutableDateTime.setDate() ignores JVM's timezone, uses UTC

closed
Joda-Time (76)
5
2012-10-08
2010-10-28
Anonymous
No

If the intent is to treat the date component of an instant separately from the time component, then I believe the that the current behavior of setDate() is flawed.

Here is a permalink to the issue I encountered that led me to create this ticket:

http://stackoverflow.com/q/4045561/252071

Expected: In a EDT JVM, using setDate() with a parsed string date of "10/27/10" results in the MutableDateTime having a date component of "10/27/10"

Actual: In a EDT JVM, sing setDate() with a parsed string date of "10/27/10" results in the MutableDateTime having a date component of "10/26/10"

Per the user Affe from stackoverflow, '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.'

Discussion

  • I suspect that using parseLocalDate() instead of parseMutableDateTime() will solve the problem. There are particular difficulties in parsing dates in the Western hemisphere when the input does not contain a GMT offset. parseLocalDate solves them,