Introduction

How you get the current date in Android depends mostly on your minimum API level. On modern Android, the cleanest answer is usually java.time, especially LocalDate.now(). On older Android versions, Calendar is the fallback you can always rely on. The most important thing is to separate "current date value" from "how you want to format it for display."

Modern Android: use LocalDate or LocalDateTime

If your app targets API level 26 and above for the code path in question, java.time is the clearest API.

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

If you also need the current time:

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

These classes are immutable, easier to read than older date APIs, and much less error-prone for normal application code.

Formatting the date for the UI

Getting the current date and displaying it are different steps. Once you have a LocalDate, format it explicitly.

1import java.time.LocalDate
2import java.time.format.DateTimeFormatter
3
4val today = LocalDate.now()
5val formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd")
6val text = today.format(formatter)
7
8println(text)

This makes the display rule obvious. It also avoids the common mistake of relying on whatever toString() happens to output.

Older-compatible fallback: Calendar

If you need code that works on older Android APIs without depending on newer java.time support in that path, Calendar remains the standard fallback.

1import java.util.Calendar;
2
3Calendar calendar = Calendar.getInstance();
4int year = calendar.get(Calendar.YEAR);
5int month = calendar.get(Calendar.MONTH) + 1; // zero-based
6int day = calendar.get(Calendar.DAY_OF_MONTH);
7
8System.out.println(year + "-" + month + "-" + day);

The + 1 on month is important because Calendar.MONTH is zero-based. That off-by-one detail is one of the biggest reasons many Android developers prefer java.time when possible.

Java example with legacy formatting

If you want a formatted string directly using older APIs:

1import java.text.SimpleDateFormat;
2import java.util.Date;
3import java.util.Locale;
4
5SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd", Locale.US);
6String today = formatter.format(new Date());
7
8System.out.println(today);

This works, but it mixes "current instant" and "formatting" in one step. For new code, java.time is usually easier to maintain.

Choose the right date concept

Another source of confusion is choosing the wrong type:

• use LocalDate if you need only the calendar date
• use LocalDateTime if you need date plus time without a zone
• use Instant or zoned types when exact cross-time-zone behavior matters

For something like "show today's date in the app," LocalDate.now() is usually the correct level of abstraction.

Common Pitfalls

The biggest mistake in old Android code is forgetting that Calendar.MONTH is zero-based. That leads to dates that look one month off.

Another issue is using Date or Calendar for new code when java.time is available and clearer.

Developers also sometimes format a date with the default locale or pattern without thinking about how the UI should really look. A date string intended for storage is not the same as a date string intended for users.

Finally, "current date" depends on time zone. If the app works across zones or server timestamps, be explicit about which zone defines "today."

One more subtle issue is testing near midnight. Code that seems correct during the day can behave differently around date boundaries, especially if background work and UI rendering happen in different zones or at slightly different times.

Summary

• On modern Android, prefer LocalDate.now() for the current date.
• Use LocalDateTime.now() only when you also need the current time.
• Use Calendar as a fallback for older-compatible code paths.
• Format dates explicitly instead of relying on toString().
• Be careful with zero-based months and time-zone assumptions.