Android
Timestamp
Current Time
Programming
Tutorial

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().

kotlin
val timestampMillis = System.currentTimeMillis()
println(timestampMillis)

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:

kotlin
val timestampSeconds = System.currentTimeMillis() / 1000
println(timestampSeconds)

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.

kotlin
1import java.time.Instant
2
3val now = Instant.now()
4val epochMillis = now.toEpochMilli()
5println(now)
6println(epochMillis)

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:

kotlin
1import java.text.SimpleDateFormat
2import java.util.Date
3import java.util.Locale
4
5val timestamp = System.currentTimeMillis()
6val formatter = SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.US)
7val formatted = formatter.format(Date(timestamp))
8
9println(formatted)

This produces a display string in the device's default time zone unless you set another one explicitly.

If you need UTC:

kotlin
1import java.text.SimpleDateFormat
2import java.util.Date
3import java.util.Locale
4import java.util.TimeZone
5
6val formatter = SimpleDateFormat("yyyy-MM-dd HH:mm:ss 'UTC'", Locale.US)
7formatter.timeZone = TimeZone.getTimeZone("UTC")
8
9println(formatter.format(Date(System.currentTimeMillis())))

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().

kotlin
1import android.os.SystemClock
2
3val start = SystemClock.elapsedRealtime()
4
5Thread.sleep(250)
6
7val elapsed = SystemClock.elapsedRealtime() - start
8println("Elapsed: $elapsed ms")

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.

kotlin
1data class Event(
2    val id: Long,
3    val createdAtMillis: Long
4)
5
6val event = Event(
7    id = 1L,
8    createdAtMillis = System.currentTimeMillis()
9)

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() and elapsedRealtime() 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.

Course illustration
Course illustration

All Rights Reserved.