What is java.time.Instant, and what does it represent?
answer
- Point on the global timeline, UTC
- epochSecond + nano since 1970-01-01T00:00:00Z
- No zone, no year/month/day fields
- atZone(...) to make it human-readable
- Date done right; use for timestamps
basics
~10 sInstant is a single point in time on the global timeline, measured as seconds and nanoseconds from the epoch (1970-01-01 00:00 UTC). It carries no time zone, so it's an unambiguous machine timestamp.
solid answer
~40 sInstant represents one exact moment on the universal timeline, stored as a count of seconds (and nanoseconds) since the Unix epoch, 1970-01-01T00:00:00Z, in UTC. It has no notion of a time zone or local calendar fields like year/month/day-of-week; it's the closest java.time equivalent of System.currentTimeMillis() but nanosecond-precise. Because it's zone-free and always UTC, it's the right type for recording when something happened, for timestamps in logs and databases, and for comparing or ordering events across machines. To present it to a human you attach a zone (instant.atZone(zoneId)) producing a ZonedDateTime. Instant.now() reads the clock; Instant.ofEpochSecond / ofEpochMilli construct from epoch counts. It implements Comparable and is immutable and thread-safe.
code
java · 7 linesInstant now = Instant.now(); // a single global moment
long secs = now.getEpochSecond(); // seconds since 1970-01-01T00:00:00Z
// The same Instant viewed in two places:
ZonedDateTime tokyo = now.atZone(ZoneId.of("Asia/Tokyo"));
ZonedDateTime newYork = now.atZone(ZoneId.of("America/New_York"));
// tokyo and newYork show different wall-clock times but are the SAME instantgo deeper
Knows Instant is a UTC point in time used for timestamps and has no zone or calendar fields.
Can convert between Instant and ZonedDateTime/OffsetDateTime and chooses Instant for stored/transmitted timestamps.
Explains epochSecond/nano internals, immutability/thread-safety, and argues why event time should be stored as an Instant and formatted only at the edge.
Sets org-wide conventions: persist instants, never local wall times for events; reasons about precision (nanos vs DB micros) and serialization formats across services.
## The problem Instant solves Computers need a way to mark *when* an event occurred that everyone, everywhere, agrees on. If you store "3 PM" you must also know *3 PM where* — that's ambiguous. **Instant** removes the ambiguity: it is a single point on a global, continuous **timeline**, independent of any country, city, or clock setting. ## What it actually stores Internally an `Instant` holds two numbers: - `epochSecond`: the number of seconds since the **Unix epoch**, defined as `1970-01-01T00:00:00Z` (the `Z` means UTC, "Zulu" time). - `nano`: a nanosecond offset (0–999,999,999) within that second, giving it far finer precision than the old millisecond-based `Date`. So an Instant is essentially "how many seconds and nanoseconds have elapsed since midnight UTC at the start of 1970." Negative values represent times before 1970. ### Key terms defined - **Epoch:** an agreed origin point for counting time. Unix/Java uses 1970-01-01 UTC. - **UTC (Coordinated Universal Time):** the world's reference clock, the zero point all time zones are described relative to. "UTC+0" is the baseline; New York in winter is "UTC-5". - **Time zone:** a region's rule for what local clock time corresponds to a given UTC moment (including daylight saving changes). Instant has *none* of this — that's the point. ## Why it has no human fields Instant deliberately does **not** expose year, month, day, hour, or minute. Those are *local* calendar concepts that only mean something once you pick a zone. The same Instant is simultaneously "3 PM in London" and "10 AM in New York." Asking an Instant "what hour is it?" is meaningless until you say *where*. ## How you create and use it ```java Instant now = Instant.now(); // current moment from the system clock Instant fromMs = Instant.ofEpochMilli(0L); // 1970-01-01T00:00:00Z Instant fromSec = Instant.ofEpochSecond(60); // one minute after the epoch ``` To show it to a person you attach a zone: ```java ZonedDateTime local = now.atZone(ZoneId.of("Europe/Paris")); ``` ## When to use it - Recording **when** something happened (event timestamps, audit logs, `created_at`). - Storing time in a **database** column (`timestamptz`) or sending it over the wire — store the unambiguous instant, format for display later. - **Comparing/ordering** events across servers in different regions. ## When NOT to use it - When you need local calendar fields (a calendar appointment, a birthday) — use `LocalDateTime`/`ZonedDateTime`. ## Properties Instant is **immutable** (every operation returns a new object), **thread-safe**, implements `Comparable<Instant>`, and supports arithmetic via `plus`/`minus` with a `Duration`. It replaces the legacy `java.util.Date` for machine timestamps and is essentially `Date` done right: nanosecond precision and an explicit "this is UTC" contract.
- How do you turn an Instant into something with a year/month/day a human can read?Attach a zone: instant.atZone(ZoneId.of("Europe/Paris")) returns a ZonedDateTime, or instant.atOffset(ZoneOffset.ofHours(2)) returns an OffsetDateTime. The Instant itself never has those fields.
- How does Instant relate to System.currentTimeMillis()?Both count from the same Unix epoch in UTC. Instant.ofEpochMilli(System.currentTimeMillis()) reconstructs the instant, but Instant offers nanosecond precision and a typed, immutable API instead of a raw long.
An Instant is like the exact tick of a single world clock photographed at one moment. The photo doesn't say what the clock on your wall reads — that depends on which country you're standing in.
saying these in an interview costs you the question
- Saying Instant has a time zone or stores local hours/days — it has neither.
- Confusing Instant with LocalDateTime; LocalDateTime has no instant on the timeline at all.
- Thinking Instant 'is in UTC' as a setting you can change — it is just a point; UTC is only how its epoch reference is defined.
- Using Instant for calendar/appointment logic that must survive DST or zone rule changes.