4

I use jodatime to parse date time strings as follows:

    public static void main(String[]args){
        String s ="16-Jul-2009 05:20:18 PDT";
        String patterns = "dd-MMM-yyyy HH:mm:ss z";

            DateTimeFormatter fm = DateTimeFormat.forPattern(patterns);
            DateTime d=fm.parseDateTime(s);
            System.out.println(d);

    }

I get

Exception in thread "main" java.lang.IllegalArgumentException: Invalid format: "16-Jul-2009 05:20:18 PDT" is malformed at "PDT"
    at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:683)

what's wrong? how to parse the timezone properly?

user775187
  • 22,311
  • 8
  • 28
  • 36

1 Answers1

10

From the DateTimeFormat javadoc:

The pattern syntax is mostly compatible with java.text.SimpleDateFormat - time zone names cannot be parsed and a few more symbols are supported. All ASCII letters are reserved as pattern letters, which are defined as follows:

Your best bet is to fall back to SimpleDateFormat and then construct DateTime based on Date#getTime().

String s = "16-Jul-2009 05:20:18 PDT";
String pattern = "dd-MMM-yyyy HH:mm:ss z";
Date date = new SimpleDateFormat(pattern, Locale.ENGLISH).parse(s);
DateTime d = new DateTime(date.getTime());
System.out.println(d);
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Hmm, I see that in the docs. Not sure I see the point of putting a pattern ("z") in the string if it cannot even be parsed. – Robert Harvey Jun 18 '11 at 04:09
  • @Rob: the world is not perfect. – BalusC Jun 18 '11 at 04:10
  • 1
    @BalusC: No, but this isn't even close. – Robert Harvey Jun 18 '11 at 04:12
  • 1
    @BalusC, I resort back to Java SimpleDateTime, I hate library like jodatime, a duplicate should always make the basic functionality at least as good as the original api, instead of wasting user time. – user775187 Jun 18 '11 at 04:13
  • JodaTime is never designed to be a replacement of `SimpleDateFormat`. It's designed to be an ISO8601 compatible replacement of `Date`. – BalusC Jun 18 '11 at 04:16
  • 1
    @user775187 The problem with timezone names is, that they are ambigous. So, the joda time folks decided to not make some arbitrary decision on behalf of the clients of their library. I don't think, that this is entirely unjustifiable... See, for example, http://www.timeanddate.com/library/abbreviations/timezones/ – Dirk Jun 18 '11 at 08:11
  • @Dirk: to me, an imperfect real world solution is better than NO solution, that's what joda folks are missing. – user775187 Jun 18 '11 at 15:45
  • @user775187 But imperfect is different from arbitrary. If the built-in Java APIs pretend to be able to parse ambigous timezone names, that means, the people, who compiled the name to offset mappings had to make choices (which zone is AST actually?) If these work for you and your customers -- great. But they are bound to fail for someone else somewhere on the globe. – Dirk Jun 18 '11 at 15:51
  • @user775187 To me the worst solution is the one that gives incorrect results and pretends all is fine. An example of a good solution is [the two-arg `ZoneId.of`](https://docs.oracle.com/javase/9/docs/api/java/time/ZoneId.html#of-java.lang.String-java.util.Map-) from `java.time`. It forces the programmer to specify how for example `PDT` is to be interpreted (if an interpretation of this abbreviation is required). – Ole V.V. May 27 '18 at 08:24