What are the implications of using ZoneDateTime versus Calendar, when converting and augmenting values?

I am unsure of what unforeseeable implications, specifically invalidation, will occur when utilizing a Calendar object, versus using a ZonedDateTime object.

I am wondering if insight can be provided to why the conversion, or parsing, of a value must be done using one framework versus the other.

I've reviewed the Java Tutorials, in reference to "legacy date-time code", and I am unable to procure where an invalidation may happen.

To paraphrase, the tutorial mentions the following.

> "The Calendar class was not type safe".

I am not concerned with type safety, parsing is only a few steps.

> "Because the classes were mutable, they could not be used in multithreaded applications".

Mutable state is not a topic.

> "Bugs in application code were common due to the unusual numbering of months and the lack of type safety".

I'm not concerned with an index versus an enumeration.

None of these points defy an antithesis for abstraction.

As a demonstration, I'll utilize both classes collectively, in an attempt to discuss their logic.

I can parse a formatted String value using SimpleDateFormat, and Calendar.

String string = "MMMM dd, yyyy '@' h:mm:ss a z";
SimpleDateFormat format = new SimpleDateFormat(string);
String value = "May 28, 2023 @ 6:50:01 pm EDT";
Calendar calendar = Calendar.getInstance();
calendar.setTime(format.parse(value));

If I print the data from calendar I receive a valid result.

System.out.println(calendar.getTimeInMillis());
System.out.printf("%tc", calendar.getTimeInMillis());

1685314201000
Sun May 28 18:50:01 EDT 2023

And, I could parse the same formatted String value using DateTimeFormatter, and ZonedDateTime.
Granted, I have to uppercase the "PM" within value—this is not a set-back.
The DateTimeParseException had even specified a character index.

DateTimeFormatter format = DateTimeFormatter.ofPattern(string);
ZonedDateTime zonedDateTime = ZonedDateTime.parse(value, format);

Similarly, if I print the data from zonedDateTime, I get a valid result.

System.out.println(zonedDateTime.toInstant().toEpochMilli());
System.out.printf("%tc%n", zonedDateTime.toInstant().toEpochMilli());
System.out.println(zonedDateTime);

1685314201000
Sun May 28 18:50:01 EDT 2023
2023-05-28T18:50:01-04:00[America/New_York]

If you review the data side-by-side, you'll find they are equivalent, thus both are valid.

If I wanted to augment the values, let's say, by adding 4 hours, since EDT is UTC-4, to derive a UTC value; I can achieve this with both classes.

For the Calendar class I can use the add method.
Which, has an extensible specification from within the Calendar class.

calendar.add(Calendar.HOUR_OF_DAY, 4);

1685328601000
Sun May 28 22:50:01 EDT 2023

Equivalently, for zonedDateTime, I can use the plusHours method.

zonedDateTime = zonedDateTime.plusHours(4);

1685328601000
Sun May 28 22:50:01 EDT 2023
2023-05-28T22:50:01-04:00[America/New_York]

Again, I'm arriving at equal values, in terms of Calendar versus ZonedDateTime.

If I subtract 1,685,314,201,000 from 1,685,328,601,000, I get 14,400,000.
14,400,000 is equivalent to, 4 hours × (60 minutes × (60 seconds × 1000 milliseconds)).

This brings me to my conclusion, on the adverse effects of using one class over another, in terms of basic parsing, and augmentation.

What is the unforeseen error that will be calculated when using one class versus the other?

For example, is one class using a more accurate year measurement, such as 365.25 days, over 365.2425?

Aside from the design implications stated by Java, where does one class prove as idiomatic over another—considering both will generate equivalent values.

I mean idiomatic from the philosophical stand-point, and not idiomatic in the paradigmatic, ideological, protestant way.

Empirical evidence need not apply.

No, they are not using a "more accurate year measurement." There is no aspect in which Calendar is incorrect or will result in values that are simply wrong.

Calendar is obsolete because it is difficult to use correctly, e.g. numbering months from 0 to 11 instead of 1 to 12.
It also conflates physical and civil times, which it's important to draw a distinction between.

It's possible to write 100% correct code with java.util.Calendar. Most people won't, though.