UPDATE: Instant has nothing to do with UTC in the timezone sense. It is related to UTC as a time standard only.

The major difference is the return type. They have different String representations because the types themselves have very different meanings.

Instant#now(Clock) returns Instant. An Instant is "[a]n instantaneous point on the time-line".

LocalDate#now(Clock) returns LocalDate. A LocalTime is "a description of the local time as seen on a wall clock".

As a result Instant#now(Clock) and LocalDate#now(Clock) mean very different things and naturally have different outcomes. The major thing they have in common is a name. Method names are dust. Refer to the types.

On a fixed Clock, both Instant.now(clock) and LocalDate.now(clock) will return constant values. The point of accepting Clock as a parameter is to be able to control things like the reference time or clock resolution.

Both are fine. And neither is recommended except for a minority of purposes.

What do you need milliseconds since the epoch for?

In Java, we can have many different ways to get the current timestamp,

For current timestamp just use Instant.now(). No need to convert to milliseconds.

Many methods from the first years of Java, also many in the standard library, took a long number of milliseconds since the epoch as argument. However, today I would consider that old-fashioned. See if you can find — or create — or more modern method that takes for instance an Instant as argument instead. Go object-oriented and don’t use a primitive long. It will make your code clearer and more self-explanatory.

As Eliott Frisch said in a comment, if this is for measuring elapsed time, you may prefer the higher resolution of System.nanoTime().

If you do need milliseconds since the epoch

Assuming that you have good reasons for wanting a count of milliseconds since the epoch, …

which one is recommended: Instant.now().toEpochMilli() or System.currentTimeMillis()[?]

Opinions differ. Some will say that you should use java.time, the modern date and time API, for all of your date and time work. This would imply Instant here. Unsg java.time is generally a good habit since the date and time classes from Java 1.0 and 1.1 (Date, Calendar, TimeZone, DateFormat, SimpleDateFormat and others) are poorly designed and now long outdated, certainly not any that we should use anymore. On the other hand I am not aware of any design problem with System.curremtTimeMillis() in particular (except what I mentioned above about using a long count of milliseconds at all, which obviously is intrinsic to both Instant.now().toEpochMilli() and System.currentTimeMillis()).

If there is a slight performance difference between the two, I have a hard time imagining the situation where this will matter.

Take the option that you find more readable and less surprising in your context.

Similar questions

• JSR 310 :: System.currentTimeMillis() vs Instant.toEpochMilli() :: TimeZone
• Java current time different values in api

Source code of Instant.now()¹, which you could easily find yourself if you use an IDE²:

public static Instant now() {
    return Clock.systemUTC().instant();
}

^{1) Copied from OpenJDK 14
2) In Eclipse, you place cursor on now() and press F3 to see the source code.
In IntelliJ, press F4, or choose View > Jump to Source, or on a Mac ⌘+click.}

It is guaranteed that all compliant versions of Java will do it that way, since it is part of the contract defined for the method, i.e. it is so documented in the javadoc of now():

This will query the system UTC clock to obtain the current instant.

That link leads to Clock.systemUTC().