We Keep Coding

SimpleDateFormat Java

I need the DATE_FORMAT for this case: "Thu Feb 17 08:50:02 UTC 2022"
The example code is this:
date = new SimpleDateFormat(DATE_FORMAT).parse(s);
where DATE_FORMAT is the format that I need to find and "s" is String "Thu Feb 17 08:50:02 UTC 2022"
Can someone help me ?

This should work for you:
Date date = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy").parse("Thu Feb 17 08:50:02 UTC 2022");

SimpleDateFormat throws parse Exception for +0100

I am trying with two sets of date with date format :
DateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss");
It works fine for the Date : Fri, 26 Aug 2016 13:55:34 +0000
Not for the Date : Tue, 06 Sep 2016 11:57:14 +0100
Throws exception for the +0100 date.
Unparseable date: "Tue, 06 Sep 2016 11:57:14 +0100" (at offset 0)
at java.text.DateFormat.parse(DateFormat.java:555)

It fails at offset 0, which means that the problem is not related to the timezone but to the day in letters.
You should set the Locale of your SimpleDateFormat.
DateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss", Locale.ENGLISH);
Date d1 = format.parse("Fri, 26 Aug 2016 13:55:34 +0000");
Date d2 = format.parse("Tue, 06 Sep 2016 11:57:14 +0100");
Works without any problem.
If you also need to retrieve the timezone, you will also have to add z to your pattern:
DateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z", Locale.ENGLISH);

You need
new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
Note the z for the time zone.
The parser ignores the zero (+0000) case if z is not supplied, but not a non-zero (+0100) case. The lenient property controls this behaviour (Acknowledge #Marko Topolnik).
Since you're using English week names, you ought to use the two-argument constructor to SimpleDateFormat, passing Locale.ENGLISH as the second parameter.

Can't convert string to date in Java, wrong timezone after conversion

I have an array of Strings with the dates e.g.:
Tue, 09 Feb 2016 14:07:00 GMT;
Tue, 09 Feb 2016 19:55:00 GMT.
Now I want to find the most recent date on this list. In order to do that, I try to deserialize these strings to java.util.Date objects and after that compare them.
The code sample of java.util.Date object generation:
strDate = "Tue, 09 Feb 2016 14:07:00 GMT";
DateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
Date date;
try {
date = format.parse(strDate);
//Result: Tue Feb 09 16:07:00 IST 2016
System.out.println("Result: " + date.toString());
} catch(ParseException e) {
e.printStackTrace();
}
My questions:
Why is the result in IST 2016 time zone and not in GMT? What does the IST 2016 stand for? Is it India Standard Time or Irish Standard Time or Israel Standard Time?
The initial string is in EEE, dd MMM format, the SimpleDateFormat pattern is also in this format, thus, why the result is in EEE, MMM dd format?
How can get a java.util.Date object in the same timezone as the initial string, in my case — GMT?
Is the approach I'm using to find the most recent date in the list is OK or there is more convenient/modern way to do that in Java 8, e.g., with the usage of LocalDateTime?

You are relying to Date.toString() to print your date when you should format it to a String with a formatter. What you are seeing is just the default pattern of Date.toString(). What you must keep in mind is that a Date does not have a timezone. You are seeing the output with the IST timezone, this must be because the current locale for the JVM is set to some specific locale for which the timezone name is "IST".
With regard to your point 4, yes, you can do it much cleaner with Java Time API introduced in Java 8. You can create a List of your strings to parse, create a DateTimeFormatter to parse it, and keep the maximum date value.
public static void main(String[] args) {
List<String> dates = Arrays.asList("Tue, 09 Feb 2016 14:07:00 GMT", "Tue, 09 Feb 2016 19:55:00 GMT");
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss z", Locale.ENGLISH);
ZonedDateTime maxDate = dates.stream()
.map(s -> ZonedDateTime.parse(s, formatter))
.max(ZonedDateTime::compareTo)
.get(); // or .orElse(null)
System.out.println(maxDate);
}
This code is using a ZonedDateTime to keep the time-zone of the incoming strings.

Your computer seems to be set to IST. To force GMT output, import java.util.TimeZone and do this in your try block:
format.setTimeZone(TimeZone.getTimeZone("GMT"));
date = format.parse(strDate);
System.out.println("Result: " + format.format(date));

How to solve Invalid Date format error in scala?

I m getting follwing error:
val formatter = ISODateTimeFormat.dateTimeParser()
scala> val date2 = "Tue Dec 29 11:11:30 IST 2015"
date2: String = Tue Dec 29 11:11:30 IST 2015
scala> formatter.parseDateTime(date2)
java.lang.IllegalArgumentException: Invalid format: "Tue Dec 29 11:11:30 IST 2015" is malformed at "ue Dec 29 11:11:30 IST 2015"
how to resolve following error??

I think you have the wrong format here - using SimpleDateFormat and a bit of googling this works:
scala> val formatter = new java.text.SimpleDateFormat("EEE MMM d HH:mm:ss Z yyyy")
formatter: java.text.SimpleDateFormat = java.text.SimpleDateFormat#73342172
scala> formatter.parse("Tue Dec 29 11:11:30 IST 2015")
res1: java.util.Date = Tue Dec 29 09:11:30 GMT 2015
edit: errr don't forget the timezone and year like I originally did ;-)

First thing to note:
Your input is not in ISO-Format and contains the name of a timezone (here: IST). You tried Joda-Time, but used an ISO-Format. This cannot work because the ISO-format pattern does not match the non-ISO-input. Second reason against Joda-Time is the fact that Joda-Time cannot parse timezone names. So following approach using a theoretically correct pattern will fail:
String input = "Tue Dec 29 11:11:30 IST 2015";
DateTimeFormatter dtf =
DateTimeFormat.forPattern("EEE MMM d HH:mm:ss z yyyy").withLocale(Locale.ENGLISH);
DateTime unparseable = dtf.parseDateTime(input);
// java.lang.IllegalArgumentException:
// Invalid format: "Tue Dec 29 11:11:30 IST 2015" is malformed at "IST 2015"
So you can only change the library. An obvious candidate using the (horrible) class SimpleDateFormat is:
String input = "Tue Dec 29 11:11:30 IST 2015";
String pattern = "EEE MMM d HH:mm:ss z yyyy";
SimpleDateFormat sdf = new SimpleDateFormat(pattern, Locale.ENGLISH);
java.util.Date jud = sdf.parse(input);
System.out.println(jud); // Tue Dec 29 10:11:30 CET 2015 (in my local tz CET=+01:00)
Okay no exception. But this does not mean that the result is automatically correct. The result can only be explained by having an offset of (+02:00 for IST). But is this true??? So let's have a closer look at the timezone involved:
TimeZone india = TimeZone.getTimeZone("Asia/Kolkata");
TimeZone israel = TimeZone.getTimeZone("Asia/Jerusalem");
System.out.println(israel.getDisplayName(false, TimeZone.SHORT)); // IST
System.out.println(india.getDisplayName(false, TimeZone.SHORT)); // IST
System.out.println(israel.getOffset(jud.getTime()) / 1000); // 7200 = +02:00
System.out.println(india.getOffset(jud.getTime()) / 1000); // 19800 = +05:30
This should trigger an alarm. Timezone names (especially abbreviations, here: IST) are often ambivalent and denote different timezones with different offsets.
So if you have got the input from Israel then you can be happy, but if from India then the result is wrong by 3:30 hours. Maybe your result will be such that it will match the India case instead of Israel. This will depend on your local timezone configuration. What so ever, don't blindly trust the parsed offsets.
The alternative Java-8:
String input = "Tue Dec 29 11:11:30 IST 2015";
ZoneId india = ZoneId.of("Asia/Kolkata");
DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
builder.appendPattern("EEE MMM d HH:mm:ss ");
builder.appendZoneText(TextStyle.SHORT, Collections.singleton(india)); // preferred zone
builder.appendPattern(" yyyy");
DateTimeFormatter dtf = builder.toFormatter(Locale.ENGLISH);
ZonedDateTime zdt = ZonedDateTime.parse(input, dtf);
System.out.println(zdt); // 2015-12-29T11:11:30+05:30[Asia/Kolkata]
// compare dangerous standard approach (not specifying your zone preference)
String pattern = "EEE MMM d HH:mm:ss z yyyy";
zdt = ZonedDateTime.parse(input, DateTimeFormatter.ofPattern(pattern, Locale.ENGLISH));
System.out.println(zdt); // 2015-12-29T11:11:30+02:00[Asia/Jerusalem]
It will work if you specify your preferred timezone but you really need to think twice before you parse timezone names. The builder approach might appear a little bit awkward but cannot be avoided due to the difficulty of the problem. So Java-8 is very fine to give you a solution here.
By the way, if you use a strict style (DateTimeFormatter.ofPattern(pattern, Locale.ENGLISH).withResolverStyle(ResolverStyle.STRICT)) then the parser will throw an exception with the message:
java.time.format.DateTimeParseException: Text 'Tue Dec 29 11:11:30 IST
2015' could not be parsed: Unable to obtain ZonedDateTime from
TemporalAccessor: {YearOfEra=2015, DayOfMonth=29, DayOfWeek=2,
MonthOfYear=12},ISO,Asia/Jerusalem resolved to 11:11:30 of type
java.time.format.Parsed
The message is somehow mysterious but I assume it is because of the ambivalent name IST.
If you are working on a platform with older JDK (Java 6 or 7) then you might consider ThreetenBP. ThreetenBP has the advantage to make a future migration easy (just changing the import statements) but my own experiments with the builder approach failed, unfortunately (even failed with the newest version v1.3.1 - maybe this depends on the underlying JDK???):
String input = "Tue Dec 29 11:11:30 IST 2015";
ZoneId india = ZoneId.of("Asia/Kolkata");
DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
builder.appendPattern("EEE MMM d HH:mm:ss ");
builder.appendZoneText(TextStyle.SHORT, Collections.singleton(india)); // preferred zone
builder.appendPattern(" yyyy");
DateTimeFormatter dtf = builder.toFormatter(Locale.ENGLISH);
ZonedDateTime zdt = ZonedDateTime.parse(input, dtf);
System.out.println(zdt); // 2015-12-29T11:11:30+02:00[Israel] // why???
Else you can try my library Time4J which works on Java-6 or 7 (or later). It works similar to Java-8:
String input = "Tue Dec 29 11:11:30 IST 2015";
TZID india = ASIA.KOLKATA;
ChronoFormatter<Moment> f = ChronoFormatter.setUp(Moment.axis(), Locale.ENGLISH)
.addPattern("EEE MMM d HH:mm:ss ", PatternType.CLDR)
.addShortTimezoneName(Collections.singleton(india)) // preferred zone
.addPattern(" yyyy", PatternType.CLDR)
.build();
System.out.println(f.parse(input)); // 2015-12-29T05:41:30Z
System.out.println(ZonalDateTime.parse(input, f)); // 2015-12-29T11:11:30UTC+05:30[Asia/Kolkata]
The error message in strict or smart parser style using
String input = "Tue Dec 29 11:11:30 IST 2015";
String pattern = "EEE MMM d HH:mm:ss z yyyy";
ChronoFormatter<Moment> f = // here smart standard style!
ChronoFormatter.ofMomentPattern(
pattern, PatternType.CLDR, Locale.ENGLISH, ZonalOffset.UTC);
f.parse(input);
will be:
Time zone name "IST" not found among preferred timezones in locale en,
candidates=[Asia/Colombo, Asia/Jerusalem, Asia/Kolkata, Europe/Dublin]
Then you will immediately see that "IST" can be associated with different timezones.

Java - unparseable date, need format to match "GMT-0400"

I have the following Java:
DateFormat formatter = new SimpleDateFormat(
"EEE MMM dd yyyy HH:mm:ss zZ (zzzz)", Locale.ENGLISH);
Calendar cal = Calendar.getInstance();
cal.set(2011, Calendar.APRIL, 1);
out.println(formatter.format(cal.getTime()));
out.println();
Date date;
try {
date = formatter
.parse("Fri Apr 01 2011 00:00:00 GMT-0400 (Eastern Daylight Time)");
} catch (ParseException e) {
out.println("Failed to parse date: " + e.getMessage());
e.printStackTrace(out);
}
This is in a servlet, and the Calendar-constructed date comes out as:
Fri Apr 01 2011 16:42:24 EDT-0400 (Eastern Daylight Time)
This looks like the same format as the date string I'm trying to parse, except for EDT-0400 versus the desired GMT-0400. The code fails when trying to parse the date string:
java.text.ParseException: Unparseable date: "Fri Apr 01 2011 00:00:00 GMT-0400 (Eastern Daylight Time)"
How can I parse such a string? This is coming from a JavaScript date in a Sencha Touch 1.1.1 model, stored in WebSQL local storage.

For some reason GMT-0400 isnt' working, and UTC-0400 is working. You can replace GMT with UTC.
Note that this part will be completely ignored - the timezone will be resolved from what's found in the brackets (at least on my machine, JDK 6)

I debugged SimpleDateFormat and it seems that it will only parse GMT-04:00 but not GMT-0400.
It will accept UTC-0400, however it will throw away the hours/minutes modifier and will incorrectly parse it as UTC. (This happens with any other timezone designation, except for GMT)
It will also parse -0400 correctly, so the most robust solution is probably to simply remove GMT from your date string.
The upshot of the story is that SimpleDateFormat is anything but simple.
Update: Another lesson is that I could've saved a lot of time by passing a ParsePosition object to the parse() method:
DateFormat formatter = new SimpleDateFormat(
"EEE MMM dd yyyy HH:mm:ss zzzz", Locale.ENGLISH);
Date date;
ParsePosition pos = new ParsePosition( 0 );
date = formatter
.parse("Fri Apr 01 2011 00:00:00 UTC-0400", pos);
System.out.println( pos.getIndex() );
Will print out 28, indicating that the parsing ended at character index 28, just after UTC.