Date.getYear（）与Calendar.get（Calendar.YEAR）-更改实现。 能行吗

Question

I am asking this question cause actually I have absolutely no way to test this case, and maybe someone could explain it to me :)

I have been working on a piece of code that was written by a person who is very new to programming. This code looks like this:

List<Date> dateList = infoFacade.getDateFrom(documentId);
for(Date from : dateList) {

    LocalDate now1 = LocalDate.now();
    int year = now1.getYear();
    int previousyear = now1.getYear()-1;
    int yearfrom = from.getYear()+1900;

        if((yearfrom == year )|| (yearfrom == previousyear )){
            idoc.setBauinfoArzvon(from); 
        }
}

I have rewritten it a little bit, so we stop using a deprecated method. It looks like this:

for (Date from : infoFacade.getDateFrom(documentId))
{
    cal.setTime(from);
    int yearfrom = cal.get(Calendar.YEAR);
    if ((yearfrom == LocalDate.now().getYear())
       || (yearfrom == (LocalDate.now().getYear() - 1)))
    {
        idoc.setDateFrom(from);
    }
}

I am worried about all that +1900 or -1900 thing. Should I add or substract something from the yearfrom variable to get the same results as in the code before refactoring?

Answer 1

Assuming you cannot change the return type of infoFacade.getDateFrom() my suggestion would be:

    ZoneId zone = ZoneId.systemDefault();
    LocalDate now1 = LocalDate.now(zone);
    int year = now1.getYear();
    int previousYear = year - 1;

    List<Date> dateList = infoFacade.getDateFrom(documentId);
    for (Date from : dateList) {
        int yearfrom = from.toInstant().atZone(zone).getYear();

        if (yearfrom == year || yearfrom == previousYear) {
            idoc.setBauinfoArzvon(from);
        }
    }

Both versions of your code implicitly rely on the JVM's time zone (which is fragile). I have made this dependency explicit. I am reading the default time zone and the current date only once to ensure consistent results. And by converting the Date first to an Instant and then to ZonedDateTime I am avoiding both the deprecated method and the old and outdated Calendar class. And any considerations about whether to add or subtract 1900 or not, which gives clearer code and fewer doubts on the part of the reader.

To answer your question more directly too: No, in your rewritten version of the code you should neither add nor subtract 1900 (or any other number). The code does give the same result. This is because Date uses a “1900-based year” (where 2018 is given as 118, for example), while the also outdated Calendar class numbers the years the same way humans do. My worry is different: If either the default time zone changes while the code is running or (unlikely, but possible) New Year passes, LocalDate.now() will not give the same result each time, so your results will be inconsistent. The JVM's default time zone can be changed at any time from another part of your program or another program running in the same JVM.

Answer 2

I have written a simple test:

public static void main(String[] args) {
        Date date = new GregorianCalendar().getTime();
        Calendar cal = new GregorianCalendar();
        cal.setTime(date);
        System.out.println(cal.get(Calendar.YEAR));
        System.out.println((LocalDate.now().getYear() - 1));
        System.out.println(LocalDate.now().getYear());
        LocalDate now1 = LocalDate.now();
        int year = now1.getYear();
        int previousyear = now1.getYear()-1;
        int yearfrom = date.getYear()+1900;
        System.out.println(year);
        System.out.println(previousyear);
        System.out.println(yearfrom);
    }

The output of this test is:

2018
2017
2018
2018
2017
2018

So both code samples are giving the same result.

BUT i will try to use the @Ole VV answer tomorrow to see what will happen.