Introduction

On Android, the most common "current timestamp" is the wall-clock time in milliseconds since the Unix epoch. The usual API for that is System.currentTimeMillis(), but it is important to distinguish wall-clock timestamps from elapsed-time measurements because they solve different problems.

Get the Current Wall-Clock Timestamp

If you need a timestamp to store in a database, send to a server, or record in a log, use epoch milliseconds.

long timestamp = System.currentTimeMillis();
System.out.println(timestamp);

This value represents current wall-clock time in milliseconds since January 1, 1970 UTC.

On supported Android runtimes, the modern Java time API offers a similar result:

1import java.time.Instant;
2
3long timestamp = Instant.now().toEpochMilli();
4System.out.println(timestamp);

The important part is the meaning of the value, not which wrapper API produced it.

Format the Timestamp for Display

Raw epoch milliseconds are ideal for storage and transport, but users usually need human-readable text.

1import java.text.SimpleDateFormat;
2import java.util.Date;
3import java.util.Locale;
4
5long timestamp = System.currentTimeMillis();
6SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault());
7String text = format.format(new Date(timestamp));
8System.out.println(text);

This is appropriate for labels, debugging output, or quick local display.

Do Not Use Wall-Clock Time for Durations

A very common mistake is using System.currentTimeMillis() to measure how long something took. That is unreliable because wall-clock time can jump if the device clock changes.

For elapsed time on Android, use SystemClock.elapsedRealtime().

1import android.os.SystemClock;
2
3long start = SystemClock.elapsedRealtime();
4// do work
5long elapsed = SystemClock.elapsedRealtime() - start;
6System.out.println(elapsed);

This clock is meant for durations, not for real-world timestamps.

Choose the Clock Based on the Question

Use wall-clock time when the question is:

• when was this event created,
• when should this record be stored,
• what time should be shown to the user.

Use elapsed time when the question is:

• how long did this request take,
• how long has the app been waiting,
• when should a timeout fire relative to now.

Those are different questions, and Android gives you different clocks because the answers have different requirements.

Store Raw Timestamps, Format Later

A practical design rule is to store timestamps as raw epoch values or normalized UTC instants and only format them when presenting them to the user. That keeps storage, synchronization, and display concerns separate.

It also makes server communication much simpler. Raw timestamps travel well across time zones, devices, and backend systems. Delaying formatting prevents locale-specific display decisions from leaking into persistence or network payloads.

Time Zones and Locale Still Matter for Display

Once you convert the timestamp to visible text, locale and time zone start to matter. A raw timestamp is universal, but a formatted string is a presentation choice.

That is why it is usually better to delay formatting until the UI layer or reporting layer, rather than storing the pretty text itself.

Common Pitfalls

A common mistake is using System.currentTimeMillis() for durations and performance timing. That is the wrong clock for elapsed-time measurement.

Another issue is formatting timestamps too early and then trying to reuse the formatted text as if it were still a machine-friendly timestamp.

Developers also sometimes assume every time-related problem on Android should use the same API. It should not.

Summary

• Use System.currentTimeMillis() for the current wall-clock timestamp in epoch milliseconds.
• 'Instant.now().toEpochMilli() is a modern equivalent on supported runtimes.'
• Format timestamps only when you need user-facing text.
• Use SystemClock.elapsedRealtime() for durations and timeout measurement.
• Pick the clock based on whether you need a real timestamp or an elapsed-time measurement.