In Java, a Date isn't just year/month/day. It's also time. When they were setting off midnight fireworks in Canberra on Jan 1 2021, I hadn't even eaten lunch on New Year's Eve. Internally, a java.util.Data is simply the number of milliseconds since midnight, Jan 1, 1970 in the Greenwich ((UTC) time zone. This is why the month/day/year constructor for java.util.Date has been deprecated for nearly 2 decades.
The no-argument Date constructor constructs based on the UTC date, which it determines from system locale settings.
There is no actual concept of month, day, or year in java.util.Date. Getting a date in and out - and in what format: MM/dd/yy, yyyy-mm-dd or whatever and what calendar (western, Judaic, hegira, or even Japanese Imperial) is the province of the various Java calendar classes, as augmented by "recent" time/date services (they're not as recent as they used to be!).
In short - take Carey's advice.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
To put what Tim said another way: stop using java.util.Date, Java.util.Calendar and its subclasses. The newer (only seven years old) classes are decsribed in the Java™ Tutorials, and they are much better.
when your children are suffering from your punishment, tell your them it will help them write good poetry when they are older. Like this tiny ad: