0

I'm trying to check if a user is older than 13 years. So I did the following.

public boolean isUserOldEnough(String birthDay) {
        Date date = null;
        try {
            date = new SimpleDateFormat("YYYY/MM/DD").parse(birthDay);
        } catch (ParseException e) {
            e.printStackTrace();
        }
        Calendar calendar = Calendar.getInstance();
        calendar.setTime(date);

        long birthTime = calendar.getTimeInMillis();
        return birthTime > getMinAge();
    }

    public long getMinAge() {
        Calendar calendar    = Calendar.getInstance();
        int      currentYear = calendar.get(Calendar.YEAR);
        calendar.set(currentYear - 13, Calendar.MONTH, Calendar.DAY_OF_MONTH);
        return calendar.getTimeInMillis();
    }

From the first method, with 2000/01/21, I get 946159200000, while the second method gives 1110033481894, how do I get the correct time from the first method?

1 : 946159200000
2 : 1110033481894

Something is wrong with the first method and I can't get it right.

xingbin
  • 27,410
  • 9
  • 53
  • 103
Relm
  • 7,923
  • 18
  • 66
  • 113
  • First `isUserOldEnough()`, second `getMinAge ` – Relm Aug 16 '18 at 15:01
  • 1
    As an aside consider throwing away the long outmoded and notoriously troublesome `SimpleDateFormat` and friends, and adding [ThreeTenABP](https://github.com/JakeWharton/ThreeTenABP) to your Android project in order to use `java.time`, the modern Java date and time API. It is so much nicer to work with. – Ole V.V. Aug 16 '18 at 15:50
  • 1
    `ChronoUnit.YEARS.between( LocalDate.parse( "2000/01/21".replace( "/" , "-" ) ) , LocalDate.now() ) > 13` – Basil Bourque Aug 16 '18 at 20:32

1 Answers1

0

You're parsing the date in a wrong format "YYYY/MM/DD", you must use "yyyy/MM/dd", try it:

Date date = null;
try {
    date = new SimpleDateFormat("yyyy/MM/dd").parse("2000/1/21");
} catch (ParseException e) {
    e.printStackTrace();
}
System.out.println(date);

it prints: Fri Jan 21 00:00:00 EET 2000
and try the wrong one:

Date date = null;
try {
    date = new SimpleDateFormat("YYYY/MM/DD").parse("2000/1/21");
} catch (ParseException e) {
    e.printStackTrace();
}
System.out.println(date);

it prints: Mon Jan 03 00:00:00 EET 2000

Edit: if a user is old enough then his birthdate's milliseconds are less than the date's before 13 years milliseconds.
Replace your code with these:

public boolean isUserOldEnough(String birthDay) {
    Date date = null;
    try {
        date = new SimpleDateFormat("yyyy/MM/dd").parse(birthDay);
    } catch (ParseException e) {
        e.printStackTrace();
    }
    Calendar calendar = Calendar.getInstance();
    calendar.setTime(date);
    long birthTime = calendar.getTimeInMillis();
    return birthTime <= getMinAge();
}

public long getMinAge() {
    Calendar calendar    = Calendar.getInstance();
    int currentYear = calendar.get(Calendar.YEAR);
    int currentMonth = calendar.get(Calendar.MONTH);
    int currentDay = calendar.get(Calendar.DAY_OF_MONTH);
    calendar.set(currentYear - 13, currentMonth, currentDay);
    return calendar.getTimeInMillis();
}
  • These troublesome classes were supplanted years ago by the modern *java.time* classes. Suggesting their use in 2018 is poor advice. – Basil Bourque Aug 16 '18 at 20:25
  • Troublesome yes but still used because in some cases they are very simple. –  Aug 16 '18 at 20:30
  • Very simple? Simpler than this one-liner using *java.time*? `ChronoUnit.YEARS.between( LocalDate.parse( "2000/01/21".replace( "/" , "-" ) ) , LocalDate.now() ) > 13` – Basil Bourque Aug 16 '18 at 20:36
  • Do you really think that every SO user is aware of every new development in Java classes? The vast majority find tutorials on the net that are 2 or 3 years old and are easy to follow and test and just copy/paste them. The Calendar class is everywhere just like SimpleDateFormat and they're easy. The problem arises when calculations are needed. –  Aug 16 '18 at 20:44
  • 1
    Do I think every SO used is aware of every new development? Of course not… that is why I posted my comment! I am trying to let you and the readers know that these old date-time classes are terrible for all purposes, and should never be used. That is why Sun, Oracle, and the JCP community all decided to adopt [JSR 310](https://jcp.org/en/jsr/detail?id=310) over four years ago, replacing them with *java.time* classes. – Basil Bourque Aug 16 '18 at 21:16
  • 1
    The further problem with `Calendar` and `SimpleDateFormat` is exactly that: We have been using them for 25 years, so tutorials telling us how to are still abundant even though we should not use those classes any longer. They may be easy to use, but judging from the number of questions on SO they are also very easy to get wrong. – Ole V.V. Aug 17 '18 at 10:10