Why Clock.systemDefaultZone().instant() returns different time than LocalTime.now()?

Question

Why does Clock.systemDefaultZone().instant() return a different time than LocalTime.now()?

I understand that LocalTime has no timezone, but it shows just what my system clock (in tray on my computer) shows, right? Both "use" default time zone (Europe/Moscow), so time shall be the same?

My computer clock is Europe/Moscow, so both shall show exactly my computer time?

System.out.println(Clock.systemDefaultZone().instant()); // 2018-03-19T10:10:27.156Z
System.out.println(Clock.systemDefaultZone().getZone()); // Europe/Moscow

System.out.println(LocalTime.now()); // 13:10:27.166

Answer 1

If I found out correctly, the Instant returned by .instant() does not take care of any timezone information. With the correct timezone (ZoneId returned by Clock.systemDefaultZone().getZone()) you can get a ZonedDateTime from the Instant though (which does provide timezone information).

Example

System.out.println(Clock.systemDefaultZone().instant());
System.out.println(Clock.systemDefaultZone().instant().atZone(Clock.systemDefaultZone().getZone()));

Output

2018-03-19T10:30:47.032Z
2018-03-19T13:30:47.048+03:00[Europe/Moscow]

Answer 2

java.​time

public abstract class Clock extends Object A clock providing access to the current instant, date and time using a time-zone. Instances of this class are used to find the current instant, which can be interpreted using the stored time-zone to find the current date and time. As such, a clock can be used instead of System.currentTimeMillis() and TimeZone.getDefault().

Use of a Clock is optional. All key date-time classes also have a now() factory method that uses the system clock in the default time zone. The primary purpose of this abstraction is to allow alternate clocks to be plugged in as and when required. Applications use an object to obtain the current time rather than a static method. This can simplify testing. Best practice for applications is to pass a Clock into any method that requires the current instant. A dependency injection framework is one way to achieve this:

 public class MyBean {
    private Clock clock;  // dependency inject
    ...
    public void process(LocalDate eventDate) {
      if (eventDate.isBefore(LocalDate.now(clock)) {
        ...
      }
    }
  }

This approach allows an alternate clock, such as fixed or offset to be used during testing. The system factory methods provide clocks based on the best available system clock This may use System.currentTimeMillis(), or a higher resolution clock if one is available. Implementation Requirements: This abstract class must be implemented with care to ensure other classes operate correctly. All implementations that can be instantiated must be final, immutable and thread-safe. The principal methods are defined to allow the throwing of an exception. In normal use, no exceptions will be thrown, however one possible implementation would be to obtain the time from a central time server across the network. Obviously, in this case the lookup could fail, and so the method is permitted to throw an exception. The returned instants from Clock work on a time-scale that ignores leap seconds, as described in Instant. If the implementation wraps a source that provides leap second information, then a mechanism should be used to "smooth" the leap second. The Java Time-Scale mandates the use of UTC-SLS, however clock implementations may choose how accurate they are with the time-scale so long as they document how they work. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. Implementations should implement Serializable wherever possible and must document whether or not they do support serialization. Implementation Note: The clock implementation provided here is based on System.currentTimeMillis(). That method provides little to no guarantee about the accuracy of the clock. Applications requiring a more accurate clock must implement this abstract class themselves using a different external clock, such as an NTP server. Since: 1.8

java.​time.​Clock

public static Clock systemDefaultZone()

Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone. This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available. Using this method hard codes a dependency to the default time-zone into your application. It is recommended to avoid this and use a specific time-zone whenever possible. The UTC clock should be used when you need the current instant without the date or time. The returned implementation is immutable, thread-safe and Serializable. It is equivalent to system(ZoneId.systemDefault()).

Returns: a clock that uses the best available system clock in the default zone, not null

See Also: ZoneId.systemDefault()

java.​time.​Clock

public abstract Instant instant() Gets the current instant of the clock. This returns an instant representing the current instant as defined by the clock.

Returns: the current instant from this clock, not null

Throws: DateTimeException - if the instant cannot be obtained, not thrown by most implementations

Answer 3

To understand those results, we must first see how the Clock is intended to work. Taking a look at the javadoc, we can see the following description for the methods:

public abstract Instant instant()

Gets the current instant of the clock.
This returns an instant representing the current instant as defined by the clock.

public abstract ZoneId getZone()

Gets the time-zone being used to create dates and times.
A clock will typically obtain the current instant and then convert that to a date or time using a time-zone. This method returns the time-zone used.

So the instant() method will get the current instant as a java.time.Instant, which is a class that always works in UTC. And the key point here is: "as defined by the clock".

The Clock class allows you to create lots of different clock definitions - such as a fixed clock that always returns the same thing - and the most common is the one returned by systemDefaultZone(), which uses the system's current date/time.

As the instant() method returns a java.time.Instant and this class works only in UTC, the result will always be UTC.

The getZone() method will return the timezone used to create dates and times, and this is done by combining the Instant (returned by instant()) with the ZoneId returned by getZone().

You can create a clock with any timezone you want, but systemDefaultZone() just uses the JVM default timezone, which is - in your case - Europe/Moscow.

When you call LocalTime.now(), it internally uses the clock returned by systemDefaultZone().

Then, it uses the results from instant() and getZone(), and combine both to get the LocalTime.

Usage

According to javadoc:

Use of a Clock is optional. All key date-time classes also have a now() factory method that uses the system clock in the default time zone. The primary purpose of this abstraction is to allow alternate clocks to be plugged in as and when required. Applications use an object to obtain the current time rather than a static method. This can simplify testing.

So I wouldn't use the clock directly. Instead, I'd use the now methods from each class, depending on what I need.

• If I want the current moment in UTC: Instant.now()
• only the current date: LocalDate.now()

and so on...

The now() method without parameters can be very handy and convenient, but it has some drawbacks. It always uses the JVM default timezone behind the scenes. The problem, though, is that the default timezone can be changed at anytime, either by JVM/system's config or even by any application running in the same VM, and you have no control over it.

To not depend on the default configurations, you can use the alternatives now(ZoneId) (which uses an explicity timezone), or now(Clock), which makes your code more testable - see examples here.

Answer 4

While some of the other Answers have correct information, here is a simple summary.

UTC

Instant is in UTC, always, by definition.

Instant instant = Instant.now()  // Captures the current moment in UTC. Your default time zone settings are irrelevant. 

Implicit default time zone

Calling LocalTime.now() implicitly applies your JVM’s current default time zone.

When you type this code:

LocalTime.now()

… the JVM at runtime does this:

LocalTime.now( ZoneId.systemDefault() )

Not obvious which is why I recommend always passing the desired/expected time zone explicitly as the optional argument.

ZoneId z = ZoneId.systemDefault() ;  // Make explicit the fact that you are intentionally relying on the user’s JVM’s current default time zone. 
LocalTime lt = LocalTime.now( z ) ;  // Capture the current moment in the Wall-clock time used by people of a particular region (a time zone).

Beware: The user’s JVM’s current default time zone can be changed at any moment during runtime. So if the zone is critical, confirm with the user as to their intended time zone, and pass as optional argument.

ZoneId z = ZoneId.of( “Africa/Tunis” ) ;  // Or “Europe/Moscow”, whatever.
LocalTime lt = LocalTime.now( z ) ;