How to Get the Date 30 Days Ago in Kotlin for Android

Date arithmetic is simple; deciding what “today” means is the part worth making explicit.

If you only need the calendar date from 30 days ago, the modern Kotlin/Android Calendar Date Calculations answer is short:

import java.time.LocalDate

val thirtyDaysAgo = LocalDate.now().minusDays(30)

LocalDate.minusDays() handles month and year boundaries for you. The production question is not how to manually count backward through a calendar. It is whether your feature means 30 calendar dates ago, the instant exactly 30 × 24 hours ago, or the start of a 30-day range in a particular time zone.

That distinction is where otherwise-correct snippets become subtle bugs.

Use LocalDate When the Requirement Is a Calendar Date

For filters such as “show transactions since 30 days ago,” a birthday cutoff, or a date-only API parameter, LocalDate is usually the clearest model:

fun dateDaysAgo(days: Long): LocalDate =
    LocalDate.now().minusDays(days)

The Android LocalDate API defines minusDays() as calendar-date arithmetic: it decrements the date while adjusting month and year fields as necessary. That means you do not need custom rules for February, 30-day months, 31-day months, or year boundaries.

Keep the result as a date for as long as possible. Converting it immediately to a formatted String throws away useful type information and makes later calculations or comparisons harder.

Make the Time Zone Explicit When “Today” Has Business Meaning

LocalDate.now() uses the system default time zone. That can be perfectly acceptable for a UI whose definition of “today” follows the device.

But many applications have a stronger rule. A banking report may follow Jakarta time even when the user travels. A backend may define reporting days in UTC. In those cases, make that decision visible:

import java.time.LocalDate
import java.time.ZoneId

fun dateDaysAgo(
    days: Long,
    zoneId: ZoneId = ZoneId.systemDefault()
): LocalDate = LocalDate.now(zoneId).minusDays(days)

val thirtyDaysAgo = dateDaysAgo(
    days = 30,
    zoneId = ZoneId.of("Asia/Jakarta")
)

The default parameter keeps ordinary calls concise while still allowing a caller to express a business-specific zone. That is a better use of Building A Reliable Md5 Kotlin Helper defaults than hiding the zone decision deep inside formatting code.

For a broader treatment of calendar boundaries, time zones, and Android date architecture, RayLabs also covers reliable calendar date calculations in Android.

Do Not Confuse “30 Days Ago” With “720 Hours Ago”

A calendar date and an instant answer different questions.

LocalDate.now(zone).minusDays(30) means “the local calendar date 30 dates before today in this zone.” If your requirement instead means an exact elapsed duration, model an instant and subtract a duration from that timeline.

This matters around daylight-saving transitions in regions that observe them. A local day does not always map cleanly to exactly 24 elapsed hours. Choosing the type from the requirement avoids trying to repair that mismatch later with formatting tricks.

Inject Clock When the Result Must Be Testable

Calling LocalDate.now() directly inside domain logic hard-codes the system clock. Android’s API also provides LocalDate.now(clock), which gives you a clean seam for deterministic tests.

import java.time.Clock
import java.time.LocalDate

class DateRangeCalculator(
    private val clock: Clock
) {
    fun daysAgo(days: Long): LocalDate =
        LocalDate.now(clock).minusDays(days)
}

A unit test can then freeze time instead of hoping the test suite never runs across midnight:

import java.time.Clock
import java.time.Instant
import java.time.ZoneId
import kotlin.test.Test
import kotlin.test.assertEquals

class DateRangeCalculatorTest {
    @Test
    fun returnsDateThirtyDaysAgo() {
        val zone = ZoneId.of("Asia/Jakarta")
        val clock = Clock.fixed(
            Instant.parse("2026-09-10T05:00:00Z"),
            zone
        )

        val result = DateRangeCalculator(clock).daysAgo(30)

        assertEquals(LocalDate.of(2026, 8, 11), result)
    }
}

This test checks the rule itself. It does not depend on the developer laptop’s current date or time zone.

Format at the Boundary, Not Inside the Calculation

If an API expects yyyy-MM-dd, format only when producing that API value:

import java.time.format.DateTimeFormatter

private val apiDateFormatter = DateTimeFormatter.ISO_LOCAL_DATE

val requestDate = thirtyDaysAgo.format(apiDateFormatter)

For user-facing text, use a formatter appropriate to the user’s locale instead of assuming that the backend’s format is also good UI copy.

Keeping calculation and presentation separate gives you one date rule that can serve an API request, a Compose screen, logging, and tests without returning a differently formatted string for every caller.

What About Older Android Versions?

The java.time classes are part of the Android platform from API level 26. If your minimum SDK is lower, check your project’s core-library desugaring configuration before adopting a java.time-based utility across the codebase. Do not silently fall back to hand-written date arithmetic just because an older device is in the support matrix.

The important architectural point stays the same: model a date as a date, choose the zone deliberately, and keep formatting outside the calculation.

Production Checklist

Before shipping a “last 30 days” feature, verify the semantics rather than only the happy-path output:

• Confirm whether the product means 30 calendar dates or 30 × 24 elapsed hours.
• Decide whether “today” follows the device zone, a business zone, or UTC.
• Test a month boundary and a year boundary.
• Test leap-year behavior when the range can cross February.
• Freeze the clock in unit tests instead of using the live system time.
• Keep the calculation typed as LocalDate until a UI or API boundary requires formatting.

The Practical Rule

For the common Android requirement “give me the date 30 days ago,” start with LocalDate.now(zone).minusDays(30). Then spend your engineering attention on the decisions the one-liner cannot make for you: which zone defines today, whether the requirement is calendar-based or duration-based, and how the clock will be controlled in tests.

That produces a utility that is still tiny, but its behavior is explicit enough to survive real product requirements.