You're confused - your code indicates you fundamentally misunderstand a few things.

That's not how you print LocalDateTime objects

For example, it's parsing just fine.

Your error lies in appending the expression parsed to a string and expecting that to be a sensible operation.

LocalDateTime represents time in human reckoning terms. They always have seconds. They can't not. They don't have a format either. They are just a fairly simplistic, "dumb" vehicle for the fields int year, month, day, hour, minute, second and no more than that.

They do not have a format. They do not know how to print themselves in a useful fashion. They have a toString() implementation which is what you get and which is evidently confusing you.

The fix is this: Never call the toString(), if you want to render one to human eyeballs, you throw them through a DateTimeFormatter with the format method.

Replace the + parsed in System.out.println("Parsing \"" + toParse + "\" with pattern \"" + pattern + "\" returns " + parsed);

With DateTimeFormatter.ISO_LOCAL_DATE_TIME.format(parsed) instead.

They aren't instants

A combo of year/month/day/hour/minute/second cannot be converted to an instant. Period. The fact that you said 'I want to do that' is therefore ringing the alarm bells.

LDTs don't represent a moment in time. Instants only represent a moment in time. You can't convert an apple into a pear.

This is the usual way to get there:

• First, you place your localdatetime in a zone. You do this with someLocalDateTimeObject.atZone(ZoneId.of("Europe/Amsterdam")) - this gets you a ZonedDateTime.
• Those you can convert to an Instant.

There are hacky ways that you should never do because the above is fundamentally how it works. Think about it: If I tell you: "Please tell me the exact Instant, in epoch-millis-in-UTC, that matches the moment "24 minutes past 3 PM, on June 25th, 2025"?

If you answer that question you are wrong. Because the only correct response to my request is ".. I do not know. What time zone are you in?". A time zone is fundamentally a part of this conversion - and therefore in your code you should make that clear. If you want to go with the system default timezone, fantastic - but you still write this in your code so everybody that reads this sees that this is happening. For example, call .atZone(ZoneId.systemDefault()).

You are possibly doing that pattern wrong

yyyy is almost never what you want. You want uuuu instead. (in yyyy, the year before the year '1' is the year '-1'. That means doing 'math' with years BC and years AD will be off by 1. uuuu says the year before '1' is the year '0'. This isn't equal to the year in 'BC' style (there is no 0AD and 0 BC; the year before the year 1 AD is the year 1 BC. "Before Christ" isn't referring to a whole year, it's referring to a single moment. It's.. confusing, I guess). It tends not to matter, except when it does. Best to just get in the habit of never using yyyy. Use uuuu. But, whatever you do, NEVER use YYYY, that is dangerous. It's a bug that tests tend not to find (YYYY is weekyear. Which matches year except on certain days very close to jan 1st, hence why tests won't find it).

Generally writing patterns is surprisingly full of landmines you can step on. Hence, it's usually a much better plan to either use one of the constants defined in the DateTimeFormatter class, or to use the .ofLocalizedDateTime methods.

Also, you should get in the habit of always explicitly passing a Locale when making DTF objects. Different cultures have different styles of writing dates and times. If you have a specific style in mind, you should make sure the code contains this assumption in writing.