striker striker - 1 year ago 161
Java Question

How to check if an offset is there in an ISO date string

Given a ISO string like this

String dateTime = "2016-07-11T16:50:22.00+05:00";

Is there a way to find an offset is present in the specific string or not using joda?

This is what the code i have done so far, to get an offset if one is present

public static String getDateTimeWithTimeZoneOffset(String dateTimeString)
DateTimeFormatter df = ISODateTimeFormat.dateTimeParser().withOffsetParsed();
DateTime nDt = df.parseDateTime(dateTimeString);
DateTimeFormatter dateFormatterWithoutMillis = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ss");
return dateFormatterWithoutMillis.print(nDt) + SPACE + nDt.getZone();

the above code gives the below output

2016-07-11T16:50:22 +05:00

but when I have a string without an offset, like this one below


The same code takes in a default time zone and prints like this

2016-07-11T16:50:22 America/Chicago

is there anyway i can check if an offset is present in the string or not, if not throw an exception?

Answer Source


The Joda-Time development team advises migration to java.time classes:

Joda-Time is the de facto standard date and time library for Java prior to Java SE 8. Users are now asked to migrate to java.time (JSR-310).

the java.time framework built into Java 8 and later. These classes supplant the old troublesome date-time classes such as java.util.Date as well as the highly successful 3rd-party Joda-Time library. See Oracle Tutorial. Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.


The OffsetDateTime class represents a moment on the timeline with an assigned offset-from-UTC. The offset is represented by the ZoneOffset class.


If your input string lacks any offset or time zone info, it is considered to be a “local” date-time. That means it is not a particular moment on the timeline, but rather a rough idea about a possible moment. Has no real meaning until you apply an offset or time zone.

The LocalDateTime class handles this kind of value.

ISO 8601

Your input string happens to comply with the ISO 8601 standard for date-time text formats.

The java.time classes use these standard formats by default when parsing/generating strings that represent date-time values. So, you can directly parse the input string without defining a formatting pattern.

Example code

The strategy here is to try parsing as if the input string includes an offset. If not, an exception (DateTimeParseException) is thrown. In that case, we try parsing again but as a LocalDateTime value. If that second attempt throws a parsing exception, then the input is completely unexpected.

Some coding-fundamentalists will protest this use of nested exception testing. While I understand their concerns as this approach can be abused, in this particular kind of situation I maintain nested exception testing is acceptable, logical, and clear.

String input = "2016-07-11T16:50:22.00"; // "2016-07-11T16:50:22.00+05:00";
Boolean hasOffset = null;
try {
    OffsetDateTime odt = OffsetDateTime.parse ( input );
    hasOffset = Boolean.TRUE;
    ZoneOffset offset = odt.getOffset ();
    System.out.println ( "input: " + input + " | hasOffset: " + hasOffset + " | odt: " + odt + " | offset: " + offset );
} catch ( java.time.format.DateTimeParseException e1 ) {
    // Perhaps input lacks offset-from-UTC. Try parsing as a local date-time.
    try {
        LocalDateTime ldt = LocalDateTime.parse ( input );
        hasOffset = Boolean.FALSE;
        System.out.println ( "input: " + input + " | hasOffset: " + hasOffset + " | ldt: " + ldt );
    } catch ( java.time.format.DateTimeParseException e2 ) {
        System.out.println ( "ERROR - Unexpected format in the input string" ); // FIXME: Handle format exception.

When run with 2016-07-11T16:50:22.00+05:00.

input: 2016-07-11T16:50:22.00+05:00 | hasOffset: true | odt: 2016-07-11T16:50:22+05:00 | offset: +05:00

When run with 2016-07-11T16:50:22.00.

input: 2016-07-11T16:50:22.00 | hasOffset: false | ldt: 2016-07-11T16:50:22

Length testing

Of course you could always test the length of the input string. Given your example inputs, those with offsets will be longer than those without. Such length-testing can be brittle or error-prone if you have multiple kinds of input.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download