Develop Reference

Exception parsing string to Date

I cannot see why this code is failing:
#Test
public void test() {
final SimpleDateFormat sdf= new SimpleDateFormat("yyyyMMddHHmm");
try {
sdf.setLenient(false);
Date d = sdf.parse("202003290230");
} catch (ParseException e){
e.printStackTrace();
}
}
I get the exception java.text.ParseException: Unparseable date.
If I set sdf.setLenient(true) then it works, but the time in the object Date returned is '03:30' and not '02:30'.
Can someone explain me what's going on in here? Thanks.

As OH GOD SPIDERS noted in a comment your real problem is that that time doesn’t exist in you default time zone because of the spring forward, the transition to summer time (DST).
java.time
I recommend that you use java.time, the modern Java date and time API, for your date and time work. The short-sighted answer is: use LocalDateTime from java.time.
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuuMMddHHmm");
String dateTimeString = "202003290230";
LocalDateTime ldt = LocalDateTime.parse(dateTimeString, formatter);
System.out.println(ldt);
Output is:
2020-03-29T02:30
A LocalDateTime is a date and time without time zone. So it doesn’t discover that the time doesn’t exist in your time zone. The result is 2:30 as in the string.
Detecting a non-existing time
It seems you’re in a Central European time zone or some other time zone where summer time began on the last Sunday in March, and the clocks were turned forward from 2 to 3 (AM). So there was no 2:30. Supposing that you want to know, you may do:
ZoneId zone = ZoneId.of("Europe/Paris");
ZonedDateTime zdt = ldt.atZone(zone);
if (zdt.toLocalDateTime().equals(ldt)) {
System.out.println("The time " + zdt + " exists");
} else {
System.out.println("The time " + ldt + " does not exist in " + zone);
}
The time 2020-03-29T02:30 does not exist in Europe/Paris
java.time too gives you 3:30 instead of 2:30 when given a time in the spring gap. So when converting back from ZonedDateTime to LocalDateTime in this case we don’t get the same time again, which we use for detecting the non-existing time.
I further recommend that you use ZonedDateTime for past dates and times, not LocalDateTime.
Java 6?
This project is made with Java6 and the company doesn't want to update
it, …
java.time has been backported, and I have tested the code above with the backport, ThreeTen Backport, see the link at the bottom.
In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
In non-Android Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310). I’m unsure whether the very latest release of ThreeTen Backport works with Java 6 or only with Java 7(+). If this is an issue, go back a few releases and find one that works with Java 6 too.
On older Android either use desugaring or the Android edition of ThreeTen Backport. It’s called ThreeTenABP. In the latter case make sure you import the date and time classes from org.threeten.bp with subpackages.
Don’t use SimpleDateFormat
The date and time classes you were trying to use, Date and SimpleDateFormat, are poorly designed and long outdated. In your case they showed a behaviour that depends on a time zone that isn’t present in the code at all, which is quite confusing. I recommend that you don’t use those classes.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
Java 8+ APIs available through desugaring
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

Date difference in days is different in different location environment

Below is giving me 279 days in local but in different server it is giving me 278 why this happening ?
String sDate = "10-11-2017";
String eDate = "16-08-2018";
Date startDate = new SimpleDateFormat(MsmConstants.DATE_FORMAT).parse(sDate);
Date endDate = new SimpleDateFormat(MsmConstants.DATE_FORMAT).parse(eDate);
long difference = startDate.getTime() - endDate.getTime();
return Math.abs(difference / (1000 * 60 * 60 * 24));

This is probably coming from some kind of rounding combined with a difference in timezones.
Since both operands on the left and right of your / operator are integral types, you are actually losing precision with that operator.
If you change your expression to: (double) difference / (1000 * 60 * 60 * 24)
you will notice that the result is actually: -278.9583333333333
The reason it is not exact days is because of daylight savings and similar date/time adjustments.
If on your PC you have different regional settings from the server, which do not have the same daylight savings, then you might have got a different number, which exceeded 279.
As a sidenote, the Java 7 and earlier date/time API was very buggy. SimpleDateFormat wasn't even thread safe, and there were lots of issues with daylight savings and similar situations. You should really move to Java 8. What you are doing would simply become: Duration.between(startDate, endDate) and the calculation would be done correctly for you.
String sDate = "10-11-2017";
String eDate = "16-08-2018";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd-MM-yyyy");
LocalDateTime startDate = LocalDate.parse(sDate, formatter).atTime(0, 0);
LocalDateTime endDate = LocalDate.parse(eDate, formatter).atTime(0, 0);
return Duration.between(startDate, endDate).toDays();
You will see that this actually gives you 279.

jbx has already in another answer explained nicely what went wrong. 10 November is in winter on the Northern hemisphere, and 16 August is in summer. Between those two dates summer time (DST) begins, which causes one day to be just 23 hours, so the difference you calculate is 1 hour short of being 279 days at you had expected and had observed locally.
java.time
Date and time math is too complicated and error-prone to do yourself the way you tried. You should always leave it to a well-proven library. Here’s the correct and modern solution.
DateTimeFormatter dateFormatter = DateTimeFormatter.ofPattern("d-MM-uuuu");
String sDate = "10-11-2017";
String eDate = "16-08-2018";
LocalDate startDate = LocalDate.parse(sDate, dateFormatter);
LocalDate endDate = LocalDate.parse(eDate, dateFormatter);
long difference = ChronoUnit.DAYS.between(startDate, endDate);
System.out.println(Math.abs(difference));
Output is the expected:
279
Since your date strings haven’t got time of day, there is no reason to use LocalDateTime. LocalDate is the correct class to use. It also makes sure that no number truncation can happen since there is always a whole number of days between two dates.
Question: Will that work on Java 7?
Yes, java.time just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

SimpleDataFormat uses the JVM's default timezone to create Date objects. In case of daylight saving time, this might result in a +/- 1 day difference between two dates.
You have a couple of options:
Explicitly set the timezone of your SimpleDateFormat objects to GMT/UTC.
Explicitly set the timezone of your JVM to GMT/UTC.
In Java 8, use the new java.time API; in earlier versions of Java use an alternative like Joda Time.

Parsing a string to a datetime does not return the correct time

In Android...I am expecting 3:12 pm as time out put of the following code but I get 4:12 pm. Whats the correct way to parse this date time format.
String dt = "2018-09-02T19:12:00-0400";
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
try {
Date date = dateFormat.parse(dt);
System.out.println(date);
} catch (ParseException e) {
e.printStackTrace();
}

Time zone
It’s best to specify explicitly in which time zone you want your output:
DateTimeFormatter inputFormatter
= DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ssXX");
DateTimeFormatter displayFormatter = DateTimeFormatter
.ofLocalizedDateTime(FormatStyle.LONG)
.withLocale(Locale.ENGLISH);
ZoneId displayZone = ZoneId.of("Pacific/Pitcairn");
String dt = "2018-09-02T19:12:00-0400";
OffsetDateTime dateTime = OffsetDateTime.parse(dt, inputFormatter);
String displayDateTime = dateTime.atZoneSameInstant(displayZone)
.format(displayFormatter);
System.out.println(displayDateTime);
This prints:
September 2, 2018 at 3:12:00 PM PST
I have used Pacific/Pitcairn time zone in my code, but you know better which time zone you want.
I am also using java.time, the modern Java date and time API. The date-time classes you are using, SimpleDateFormat and Date, are considered long outdated, and java.time is so much nicer to work with.
What went wrong in your code?
Your way of parsing your date string is correct and produces the correct Date.
When printing the Date, you are implicitly calling toString. The outdated Date class has a peculiar and confusing toString method: it grabs the JVM’s time zone setting and uses it for producing the string. So depending on your default time zone, you can get any hour of day in the output. So it seems your JVM’s time zone setting didn’t correspond to what you had expected.
Since you expected 3:12 PM from your input of 19:12:00-0400, I take it that you want a time zone that is at offset -08:00 from UTC in September. If for example your default time zone was America/Los_Angeles, the standard time of which is at -08:00, you would get Sun Sep 02 16:12:00 PDT 2018 because summer time (daylight saving time) is in effect in California in September, so the offset is -07:00.
Relying on your JVM’s default time zone is always fragile since the setting may be changed at any time by other parts of your program or by other programs running in the same JVM.
Question: Can I use java.time on Android?
Yes, java.time works nicely on older and newer Android devices. It just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26, I’m told) the modern API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

How to parse time (hour, minute) from a string?

Anybody know how to parse time (hour, minute and AM/PM) from a string that looks like "01:20" -> 1:20AM and "21:20" -> 9:20PM? Most solutions out there seem to assume or require a Date or Calendar object.
My input time is actually coming from a TimePickerDialog (specifically, this MaterialDateTimePicker implementation, so I receive only the hourOfDay, minute and seconds (integers).
I want to be able to format the time that the user picked in a friendly way, i.e 12:30PM, 02:15AM, etc.
I am trying to use Joda Time:
fun formattedTime(timeStr: String): String {
// Get time from date
val timeFormatter = DateTimeFormat.forPattern("h:mm a")
val displayTime = timeFormatter.parseLocalTime(timeStr)
return displayTime.toString()
}
but I get this error with an input string such as "1:20":
java.lang.IllegalArgumentException: Invalid format: "1:20" is too short
I have also looked into SimpleDateFormat but it seems to require a full date-time string such as in this related question

As #ole-v-v pointed out, SimpleDateFormat has seen better days - so today you can make use of the java.time package to do the job:
java.time.format.DateTimeFormatter target2 =
java.time.format.DateTimeFormatter.ofPattern("h:mm a");
java.time.format.DateTimeFormatter source2 =
java.time.format.DateTimeFormatter.ofPattern("HH:mm");
System.out.println("01:30 -> " + target2.format(source2.parse("01:30")));
System.out.println("21:20 -> " + target2.format(source2.parse("21:20")));
Yields the result of
01:30 -> 1:30 AM
21:20 -> 9:20 PM
as expected.
In Joda-Time you would code it as #meno-hochschild pointed out in his answer below.
Using SimpleDateFormat it will look like this:
SimpleDateFormat target = new SimpleDateFormat("h:mm a");
SimpleDateFormat source = new SimpleDateFormat("HH:mm");
System.out.println("01:30 -> " + target.format(source.parse("01:30")));
System.out.println("21:20 -> " + target.format(source.parse("21:20")));
This will parse from 24h times to 12 hours display
01:30 -> 1:30 AM
21:20 -> 9:20 PM
It all depends on the format for the hours - for parsing you'll want 24h hours (format HH), for output you want 12 hours plus am / pm - format is h.
If you want 01:30 to be PM you'll have to add that to the string to be parsed somehow:
System.out.println("01:30 pm-> " + target.format(target.parse("01:30 pm")));
resulting in
01:30 pm-> 1:30 PM

The accepted answer is correct. However, I am astonished to see the old classes like SimpleDateFormat although the OP has explicitly first desired a Joda answer (see the tags of the question). So I post here the Joda answer as supplement:
DateTimeFormatter target = DateTimeFormat.forPattern("h:mm a").withLocale(Locale.ENGLISH);
DateTimeFormatter source = DateTimeFormat.forPattern("HH:mm");
System.out.println("01:30 -> " + target.print(source.parseLocalTime("01:30")));
System.out.println("21:20 -> " + target.print(source.parseLocalTime("21:20")));
01:30 -> 1:30 AM
21:20 -> 9:20 PM
I advise not to mix two different time libraries (the OP obviously uses Joda-Time-Android).

Your two good options are Joda-Time and java.time.
Since you receive hourOfDay, minute and seconds as integers from the time picker, you don’t need to do any parsing.
java.time
DateTimeFormatter timeFormatter = DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT)
.withLocale(Locale.US);
LocalTime time = LocalTime.of(hourOfDay, minute, second);
String displayTime = time.format(timeFormatter);
System.out.println(displayTime);
This prints the time like this:
11:45 PM
Rather than an explicit format pattern string I am relying on the built-in localized format for the US locale. It has put a space between the minutes and PM (or AM). I believe your users will be happy about that. If not, you will need to use DateTimeFormatter.ofPattern("h:mma", Locale.US) instead.
Joda-Time
If you are already using Joda-Time and don’t have a reason for changing at this point, sticking to it is reasonable. You may use the LocalTime(int hourOfDay, int minuteOfHour, int secondOfMinute) constructor. Then proceed as in Meno Hochschild’s answer. It’s a good and knowledgeable answer.
Note that Joda-Time is considered to be a largely “finished” project.
No major enhancements are planned. If using Java SE 8, please migrate
to java.time (JSR-310).
(Quoted from the Joda-Time homepage)
Stay away from SimpleDateFormat
Stay far away from the SimpleDateFormat class. It can be made to work for the job, but it is not only long outdated, it is also notoriously troublesome.
Question: Can I use java.time on Android?
Yes, java.time works nicely on older and newer Android devices. It just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26, I’m told) the modern API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.timeto Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

Android Unparseable date: "2017-12-01 00:00:00+01"

I am trying to parse the date-time string 2017-12-01 00:00:00+01.
My pattern is as follows:
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ssZ");
The exception “Unparseable date: "2017-12-01 00:00:00+01"” is thrown with Android 7 and above.
I found another pattern: "yyyy-MM-dd HH:mm:ssX" but it works only with Android 7 and above.
I tried this workaround "yyyy-MM-dd HH:mm:ssZZZZZ" that I found here, but it doesn't work.
Is there a solution that will also work with Android below Android 7?

I will give you the good solution and the hack.
java.time
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ssX");
OffsetDateTime dateTime = OffsetDateTime.parse(dateTimeString, formatter);
System.out.println(dateTime);
This prints
2017-12-01T00:00+01:00
This is the good solution: java.time, the modern Java date and time API. There are at least two reasons why you would want to do this on Android.
The SimpleDateFormat class that you have been using is not only long outdated, it is also notoriously troublesome, so I would recommend you don’t use it anyway, and the modern API is so much nicer to work with.
Your time zone offset of +01 is an ISO 8601 offset. While only later vertsions of SimpleDateFormat can parse this, java.time has excelled at the ISO 8601 standard from when it came out, so this is a safe bet.
I should say you have a nice opportunity for going future-proof.
Your time of day of 00:00:00 seems to suggest you’re only interested in the date? If so, java.time has one more good offer for you, the LocalDate class represents a date without time of day:
LocalDate date = dateTime.toLocalDate();
This gives a LocalDate of 2017-12-01.
The hack
You may just append minutes of offset of 00 to your string, and the formatter in your question will parse it:
dateTimeString += "00";
Question: how do I use java.time on older Android?
If java.time is not built-in on your Android device, you get ThreeTenABP and add it to your project, and then import org.threeten.bp.OffsetDateTime, org.threeten.bp.LocalDate and org.threeten.bp.format.DateTimeFormatter. See the links below. The code is unchanged from above.
Links
Oracle tutorial: Date Time, explaining how to use java.time.
Java Specification Request (JSR) 310, where the modern date and time API was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

The problem lies in the "+01" time zone suffix. This is not a valid representation of a time zone under either the "General time zone" rules or the "RFC 822 time zone" rules.
You can change your SimpleDateFormat to "yyyy-MM-dd HH:mm:ss", which will allow the date to be parsed but will ignore the time zone suffix. Then you can manually parse the time zone suffix and modify your Date accordingly.
Alternatively, if you can somehow change your input to include offset minutes in addition to hours (i.e. change the time zone suffix to "+0100"), then your existing date format will work just fine. Including minutes in addition to hours makes the time zone suffix parseable according to RFC 822.