Jesper has already given you short answers to your questions.

The no-arg method LocalDate.html#now obtains the current date from the system clock in the default (system) time-zone. Therefore, when you print LocalDate.now() in Madrid, India and New York, at the same time, you may get different results (depending on what time you do it).

Demo:

import java.time.LocalDate;
import java.time.ZoneId;

public class Main {
    public static void main(String[] args) {
        System.out.println(LocalDate.now(ZoneId.of("Europe/Madrid")));
        System.out.println(LocalDate.now(ZoneId.of("Asia/Kolkata")));
        System.out.println(LocalDate.now(ZoneId.of("America/New_York")));
    }
}

Output:

2022-09-28
2022-09-29
2022-09-28

Note: to understand this difference, check the output of the following program:

import java.time.LocalDateTime;
import java.time.ZoneId;

public class Main {
    public static void main(String[] args) {
        System.out.println(LocalDateTime.now(ZoneId.of("Europe/Madrid")));
        System.out.println(LocalDateTime.now(ZoneId.of("Asia/Kolkata")));
        System.out.println(LocalDateTime.now(ZoneId.of("America/New_York")));
    }
}

Result:

2022-09-28T21:03:56.438167
2022-09-29T00:33:56.443577
2022-09-28T15:03:56.444049

However, a LocalDate object does not store the time-zone information. Therefore, when you print an object of LocalDate (i.e. LocalDate#toString), the printed value will remain the same irrespective of the system time-zone.

A java.util.Date object too does not store the time-zone information. It stores the number of milliseconds from January 1, 1970, 00:00:00 GMT. However, when you print an object of java.util.Date (i.e. Date#toString), it uses the default (system) time-zone to print the value i.e. if you print an object of java.util.Date on systems with different time-zones set to them, you will get different results.