Introduction

In modern Android code, the current date and time should usually come from the java.time API, not from the older Date and Calendar classes. The right class depends on what you actually need: an absolute timestamp, a local calendar date, or a formatted value for display.

Use java.time for New Android Code

Android's current guidance and API references support java.time, and core library desugaring makes a substantial subset available on older Android versions as well. That means new application code can usually start with the same date-time types you would choose on the JVM more generally.

If you need the current moment on the timeline, use Instant.now():

1import java.time.Instant
2
3val now: Instant = Instant.now()
4println(now)

This is the best representation for logging, server communication, and stored timestamps because it is not tied to the user's local time zone.

Pick the Type That Matches the Job

java.time is easier to use than legacy APIs partly because each type represents one concept clearly.

• 'Instant is an absolute point in time.'
• 'LocalDate is a calendar date with no clock time.'
• 'LocalTime is a clock time with no date.'
• 'LocalDateTime is a date and time with no zone.'
• 'ZonedDateTime is a date and time in a specific zone.'

If the app only needs today's date on the device, LocalDate.now() is more honest than Instant.

1import java.time.LocalDate
2
3val today = LocalDate.now()
4println(today)

If the app needs the current device-local wall clock time with zone awareness, use ZonedDateTime.now():

1import java.time.ZonedDateTime
2
3val localNow = ZonedDateTime.now()
4println(localNow)

Choosing the narrowest correct type prevents later confusion about whether a value is suitable for storage, display, or arithmetic.

Format for Display with DateTimeFormatter

Once you have the current value, formatting is the next step. DateTimeFormatter gives you explicit control and also supports localized formats.

1import java.time.ZonedDateTime
2import java.time.format.DateTimeFormatter
3import java.time.format.FormatStyle
4
5val now = ZonedDateTime.now()
6val formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM)
7val text = now.format(formatter)
8
9println(text)

This is often better than hard-coding a pattern because it respects the user's locale conventions. If the product requires a fixed format, a pattern-based formatter is still fine:

val fixed = now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))
println(fixed)

Treat Time Zones as a First-Class Decision

The most common date-time bug is using local time where an absolute timestamp was required. If your app stores values in a database or sends them to a server, capture an Instant and convert to a display zone only at the UI boundary.

1import java.time.Instant
2import java.time.ZoneId
3
4val createdAt = Instant.now()
5val torontoTime = createdAt.atZone(ZoneId.of("America/Toronto"))
6
7println(createdAt)
8println(torontoTime)

This keeps the stored value stable while still allowing local presentation later.

Legacy APIs Still Exist, but Use Them Only When Required

You will still see older Android examples based on Calendar.getInstance() or Date(). Those APIs are not broken, but they are more mutable and less expressive.

1import java.util.Calendar;
2
3Calendar calendar = Calendar.getInstance();
4int year = calendar.get(Calendar.YEAR);
5int month = calendar.get(Calendar.MONTH) + 1;
6int day = calendar.get(Calendar.DAY_OF_MONTH);

Use that style only when maintaining old code or integrating with an API that already depends on it. New code is easier to read and test with java.time.

Keep Retrieval Separate from UI Refresh

Getting the current time is cheap. The more important design question is how often the UI should update and who owns that schedule. A clock label, countdown, or status timestamp should separate time acquisition from the UI refresh mechanism.

For example, the current time can come from Instant.now() or ZonedDateTime.now(), while a coroutine, Handler, or lifecycle-aware state holder controls when the screen redraws. That separation keeps your date-time logic from getting tangled up with rendering behavior.

Common Pitfalls

• Using LocalDateTime for values that really need an absolute timestamp or zone information.
• Reaching for Calendar in new code out of habit.
• Formatting local device time for storage or API exchange without capturing the zone or offset.
• Hard-coding display formats where localized formatting would be better for users.
• Mixing time retrieval logic with UI scheduling logic in one hard-to-test code path.

Summary

• Prefer java.time in modern Android code.
• Use Instant for absolute timestamps and LocalDate or ZonedDateTime for local values as needed.
• Format values with DateTimeFormatter, preferably localized when appropriate.
• Store absolute time and convert to local time for display.
• Use legacy Calendar only when you are forced to maintain older code.