Android Get Current timestamp?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
On Android, "current timestamp" usually means the current Unix time, most often in milliseconds since 1970-01-01 UTC. The correct API depends on what you want: wall-clock time for logging or persistence, or a monotonic clock for measuring elapsed duration.
The Common Answer: System.currentTimeMillis()
If you want the current wall-clock timestamp, use System.currentTimeMillis().
This returns Unix time in milliseconds. It is suitable for:
- database timestamps
- API payloads
- log records
- comparing real-world times
If you need seconds instead of milliseconds:
Be explicit about units. Many bugs come from mixing seconds and milliseconds.
Modern Date-Time API
On newer Android versions, or when using Java time support, Instant.now() is often clearer.
This is useful when you want both a timestamp and a richer time object for formatting or conversion.
If you store values in JSON or send them to a backend, Instant also makes it easier to keep the meaning explicit: it represents an absolute moment in time, not a local date-time.
Formatting for Display
A timestamp is not usually what users should see directly. Convert it to a readable string:
This produces a display string in the device's default time zone unless you set another one explicitly.
If you need UTC:
Do Not Use Wall-Clock Time for Measuring Duration
This is the most important design distinction. System.currentTimeMillis() can move backward or jump forward if the user changes device time or network time sync adjusts the clock. That makes it a poor choice for elapsed-time measurement.
For durations, use a monotonic clock such as SystemClock.elapsedRealtime().
Use this for:
- measuring task duration
- timeout logic
- performance timing
- retry backoff calculations
This is not a Unix timestamp. It is time since boot, including sleep.
Persisting Timestamps
If you save a timestamp to Room, SQLite, or a remote API, the safest representation is usually a Long in UTC milliseconds since epoch.
That keeps storage simple and avoids locale-specific parsing problems. You can always format the value later for display.
Choosing the Right Clock
Use System.currentTimeMillis() or Instant.now() when the timestamp must represent a real calendar moment. Use SystemClock.elapsedRealtime() when you care about how much time has passed on the device.
Those are different tools, and confusing them causes subtle bugs:
- expired token checks may fail
- retry timers may fire too early or too late
- analytics durations may become negative
The correct answer starts with the purpose of the value, not the syntax of the API.
Common Pitfalls
- Using
System.currentTimeMillis()for elapsed timing. Wall-clock time can change and should not be used for duration measurement. - Mixing seconds and milliseconds between app code and backend APIs. Always document the unit.
- Formatting timestamps without thinking about time zone. A correct instant can still display the wrong local time.
- Storing human-readable date strings instead of numeric epoch values. Strings are harder to compare, sort, and parse safely.
- Assuming
Instant.now()andelapsedRealtime()solve the same problem. One is for real-world time, the other is for monotonic timing.
Summary
- '
System.currentTimeMillis()is the standard way to get the current Unix timestamp on Android.' - '
Instant.now()is a cleaner modern API when you want a richer time object.' - Use timestamps for storage, logs, and API payloads, then format them separately for display.
- Use
SystemClock.elapsedRealtime()for measuring elapsed time or implementing timeouts. - Always keep track of units and time zones when moving timestamps between systems.

