Java Date & Time API (java.time)

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());  // required for java.time support at all
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);  // use readable ISO-8601 strings instead of raw arrays

public class Event {
    private ZonedDateTime startTime;
    // getters/setters
}

String json = mapper.writeValueAsString(event);
// Produces: {"startTime":"2024-06-01T14:30:00-04:00[America/New_York]"} -- readable, timezone-preserving ISO format

Common follow-ups: Why doesn't Jackson support java.time types out of the box, requiring a separate module registration?;What's the specific JSON format difference between serializing a ZonedDateTime versus an Instant, and why does that difference matter for API consumers?

// Store in UTC as the source of truth
Instant createdAt = Instant.now();  // inherently UTC-based, unambiguous
database.save("created_at", createdAt.toString());  // e.g. "2024-06-01T18:30:00Z"

// Convert to the user's local timezone ONLY when displaying, never for storage
ZonedDateTime userLocalTime = createdAt.atZone(ZoneId.of(userPreferredTimezone));
display(userLocalTime);

Common follow-ups: What specific problems would arise if timestamps were instead stored already-converted to each user's local timezone in the database?;How does storing an explicit UTC offset differ from storing a full IANA timezone identifier (like America/New_York), and when does that distinction matter?

// Fixed-instant recurrence: exactly 24 hours, regardless of any DST transition
Instant nextHealthCheck = lastCheck.plus(Duration.ofHours(24));

// Calendar-based recurrence: same LOCAL time each day, correctly adjusting across DST
ZonedDateTime nextDigestEmail = lastDigest.plusDays(1);  // still 9:00 AM local time, even across a DST transition
// Using Duration.ofDays(1) added to an Instant here would be WRONG -- it would drift by an hour on DST transition days

Common follow-ups: How would you test this specific DST-crossing behavior reliably in an automated test suite, given DST transitions only occur on specific calendar dates?;What's the correct modeling choice for a recurrence that should happen 'every 2 weeks at the same local time' -- fixed-instant or calendar-based?

// Relies on the JVM's system default timezone -- could vary across different servers!
LocalDate today = LocalDate.now();

// Explicit, unambiguous, and consistent regardless of server configuration
LocalDate todayUtc = LocalDate.now(ZoneOffset.UTC);
LocalDate todayNy = LocalDate.now(ZoneId.of("America/New_York"));

System.out.println(todayUtc);  // always reflects the current UTC date, unaffected by server timezone config

Common follow-ups: What determines a JVM's default timezone, and can it be overridden via a system property or command-line flag?;Why might relying on the system default timezone be especially risky in a containerized or cloud deployment environment?

boolean isLeap = Year.isLeap(2024);  // true
boolean isLeap2 = Year.of(2024).isLeap();  // equivalent, true

YearMonth february2024 = YearMonth.of(2024, 2);
System.out.println(february2024.lengthOfMonth());  // 29, correctly leap-year-aware

YearMonth february2023 = YearMonth.of(2023, 2);
System.out.println(february2023.lengthOfMonth());  // 28, correctly non-leap-year-aware

Common follow-ups: What's the specific Gregorian calendar rule exception (century years) that a naive 'divisible by 4' leap-year check would incorrectly get wrong?;How does YearMonth differ from simply using LocalDate with a placeholder day value for representing a year-month combination?