I'm having an issue with Date library current week. When you google it's week 11, but my function returns 12. In terms of location, I am in South Africa, but the same issue is reported by someone in Germany who is testing the application. I wrote below code to test this in a small piece of code and I see when I get calendar using new Date() library, it's returning 12, but when I use Localdate.now() it's returning 11.

I updated the Dockerfile jdk initially it was jdk8 and now it's openjdk11. Can this be the reason I am getting different results? Is new Date() no longer supported in Java 11?

Below is the code snippet. I would love if some can assist me on this.

package com.company;

import java.time.LocalDate;
import java.time.temporal.ChronoField;
import java.util.Calendar;
import java.util.Date;

public class CalenderLibrary {
    private static Calendar cal = Calendar.getInstance();

    public static void main(String[] args) {
        Date date = new Date();
        String calendarWeekFromEvent = getCalendarWeekFromEventWithDate(date);
        System.out.println("Date: {} "   calendarWeekFromEvent);

        LocalDate localDate = LocalDate.now();
        String localDate1 = getCalendarWeekFromEventWithLocalDate(localDate);
        System.out.println("LocalDate: {} "   localDate1);


    }

    private static String getCalendarWeekFromEventWithLocalDate(LocalDate date) {
        return String.valueOf(date.get(ChronoField.ALIGNED_WEEK_OF_YEAR));
    }

    private static String getCalendarWeekFromEventWithDate(Date date) {
        cal.setTime(date);
        return String.valueOf(cal.get(Calendar.WEEK_OF_YEAR));
    }
}

Results:

Date: {} 12

LocalDate: {} 11

CodePudding user response：

java.util.Date and java.util.Calendar are not deprecated, and still work as they always have. However, how they work is difficult to use, which is why java.time classes are recommended instead.

What you are seeing is the difference between WEEK_OF_YEAR (which depends on the locale) and ALIGNED_WEEK_OF_YEAR (which is the same in all locales).

When setting or getting the WEEK_OF_MONTH or WEEK_OF_YEAR fields, Calendar must determine the first week of the month or year as a reference point. The first week of a month or year is defined as the earliest seven day period beginning on getFirstDayOfWeek() and containing at least getMinimalDaysInFirstWeek() days of that month or year. Weeks numbered ..., -1, 0 precede the first week; weeks numbered 2, 3,... follow it. Note that the normalized numbering returned by get() may be different. For example, a specific Calendar subclass may designate the week before week 1 of a year as week n of the previous year.

ALIGNED_WEEK_OF_YEAR represents concept of the count of weeks within the period of a year where the weeks are aligned to the start of the year. This field is typically used with ALIGNED_DAY_OF_WEEK_IN_YEAR.

For example, in a calendar systems with a seven day week, the first aligned-week-of-year starts on day-of-year 1, the second aligned-week starts on day-of-year 8, and so on. Thus, day-of-year values 1 to 7 are in aligned-week 1, while day-of-year values 8 to 14 are in aligned-week 2, and so on.

And for the locale difference:

// returns DayOfWeek.MONDAY
WeekFields.of(Locale.forLanguageTag("de-DE")).getFirstDayOfWeek();

// returns DayOfWeek.SUNDAY
WeekFields.of(Locale.forLanguageTag("en-ZA")).getFirstDayOfWeek();

To get the unaligned week of year using the current system local with java.time:

LocalDate.now().get(WeekFields.of(Locale.getDefault()).weekOfYear())

If you want to be locale-independent, then there is ISO.weekOfYear() if you want the week to start on a Monday, and SUNDAY_START.weekOfYear() for a Sunday.

CodePudding user response：

The old, much-derided Date and Calendar classes have always been confusing and difficult to use properly, particularly in a multi-threaded context.Java 8’s JSR 310 implementation offers specific classes for:

The old date library included only a single time representation class – java.util.Date, which despite its name, is actually a timestamp. It only stores the number of milliseconds elapsed since the Unix epoch.