将日期字符串转换为Joda-Time中的datetime对象？

Question

I have a date string similar to:

"2014-04-10T00:00:00.000"

So I need to convert this to a Joda-Time DateTime object.

Here is my code :

String datePattern = "yyyy-MM-dd'T'HH:mm:ss.SSS";
DateTimeFormatter dateFormatter = DateTimeFormat.forPattern(datePattern);

currentCard.setStartDate("2014-04-10T00:00:00.000");
currentCard.setEndDate("2015-04-10T00:00:00.000");

DateTime startDateTime = dateFormatter.parseDateTime(currentCard.getStartDate());
DateTime endDateTime = dateFormatter.parseDateTime(currentCard.getEndDate());

if (startDateTime.isBeforeNow() && endDateTime.isAfterNow()) {
    currentCard.setActive(true);
} else {
    currentCard.setActive(false);
}

It tells me string is too short

Answer 1

I believe the correct syntax for the date pattern is "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" . That way the Z is literally used.

Answer 2

While the other answers are correct, both the answers and your question are working too hard.

ISO 8601 Format

The format of the string in question, "2014-04-10T00:00:00.000", is standard ISO 8601 format. The DateTime class in Joda-Time has a built-in ISO 8601 parser/formatter built-in, used by default. So no need to instantiate a formatter. Merely pass the string to the constructor of DateTime .

Time Zone

Specify a time zone by which to interpret that date-time value. Otherwise the JVM's current default time zone is applied.

Example:

DateTimeZone timeZoneMontréal = DateTimeZone.forID( "America/Montreal" );

Example Code

Some example code using Joda-Time 2.5.

DateTime dateTime = new DateTime( "2014-04-10T00:00:00.000", DateTimeZone.UTC );

If that string represented a wall-time† moment in Québec rather than UTC , then specify that time zone by which the string should be understood while parsing.

DateTime dateTime = new DateTime( "2014-04-10T00:00:00.000", timeZoneMontréal );

Specify Format

As per the comment by Meno Hochschild , you may prefer to specify the expected format of the incoming String. Joda-Time has many pre-defined formatters built-in, as well as permitting you to define your own. In this case, our string lacks a time zone offset at the end, so we specify the formatter known as dateHourMinuteSecondFraction .

What if the incoming string is malformed or using an unexpected format? An exception is thrown. For robust code, trap for that exception.

String input = "2014-04-10T00:00:00.000";
DateTimeZone timeZoneMontréal = DateTimeZone.forID( "America/Montreal" );
DateTimeFormatter formatter = ISODateTimeFormat.dateHourMinuteSecondFraction().withZone( timeZoneMontréal );
DateTime dateTime = null;
try {
    dateTime = formatter.parseDateTime( input );
} catch ( IllegalArgumentException e ) {
    System.out.println( "Unexpected format of incoming date-time string: " + input + ". Exception: " + e ); // Handle exception for bad input.
}

Adjust to UTC for comparison.

DateTime dateTimeUtc = dateTime.withZone( DateTimeZone.UTC );

Dump to console.

System.out.println( "dateTime: " + dateTime );
System.out.println( "dateTimeUtc: " + dateTimeUtc );

When run.

dateTime: 2014-04-10T00:00:00.000-04:00
dateTimeUtc: 2014-04-10T04:00:00.000Z

---

† Wall-Time = The time as usually seen on some clock on some wall in some locality.

Answer 3

Regarding your first edit using the pattern "yyyy-MM-dd'T'HH:mm:ss.SSSZ" and experiencing a parse problem with Z-input, it is obviously a version problem , see here:

On Joda-Time-release-notes for change 1.6 to 2.0 =>

"Allow 'Z' and 'ZZ' in format patterns to parse 'Z' as '+00:00' [2827359]"

So the solution is to use the newest version of Joda-Time. Note that the use of the pattern symbol Z is more powerful than just to use a literal 'Z' in pattern expression because any ISO-8601-compatible string might not only contain "Z" at the end but also offsets like "+0200". And if the offset might contain a colon (example "+05:30") then you should use the double ZZ in your pattern.

Comment about your edit to remove the pattern symbol Z:

In that case I do not see any exception with version 2.1. Joda-Time will just interprete the input as local time in system timezone and add the appropriate timezone offset. Anyway, you have to adapt your pattern to expected inputs, not otherwise around.