Lectures

Let’s break down why storing a date as a String is a trap: strings are compared lexicographically (and break sorting), don’t guarantee validity (like 2026-13-40), and create ambiguous formats (for example, 01.02.2026). Using a mini-case with expenses, we’ll see how “a string leaks into logic”, and then we’ll introduce discipline: a single ISO format yyyy-MM-dd, normalization through one function, and safe handling of bad input via null.

We break down why, when working with time, it is important to choose a type by meaning: how Instant differs from “local clock time”, when to use LocalDate and LocalDateTime, why TimeZone is needed, and how to convert Instant ↔ LocalDateTime. We also discuss Kotlin 2.3 ( import kotlin.time.Clock/ Instant) and common mistakes that lead to “time-related” bugs.

We break down how to work with “current time” correctly in Kotlin: get a moment in time via Clock.System.now() as an Instant, compare moments with the >/ < operators, compute the difference as a Duration, sort events by time using sortedBy/ sortedDescending, and fix typical mistakes (many calls to now(), sorting by strings, unit mix-ups, and “calendar” arithmetic).

We cover a disciplined approach to working with date and time in Kotlin via kotlinx.datetime: how parsing differs from formatting, why ISO‑8601 is convenient for storage and exchange, how parse() and toString() work, how to safely handle input errors via runCatching and getOrNull(), and how to manually create a “human-friendly” format (for example, dd.MM.yyyy) and neatly integrate it into a console application.

We break down why the calendar and the timeline are different models: when to choose LocalDate and when Instant, how DatePeriod differs from Duration, how to correctly get the “start of day” via TimeZone and atStartOfDayIn(...), and why DST breaks the intuition that “a day = 24 hours”. At the end — a practical case for BudgetBuddy and a list of common mistakes.