Java Date and Time Exercises: 30 Coding Problems with Solutions

import java.time.LocalDate;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        System.out.println("Today's date: " + today);
    }
}Code language: Java (java)

Explanation:

• LocalDate.now(): A static factory method that reads the system clock and returns today’s date in the JVM’s default time zone, with no time-of-day information at all.
• LocalDate: Deliberately models only a calendar date, year, month, and day, which keeps it simple for use cases like birthdays or due dates that should never carry a time component.
• Default formatting: Printing today directly relies on LocalDate‘s built-in toString(), which always produces the ISO-8601 yyyy-MM-dd format.
• Alternative: LocalDate.now(ZoneId.of("America/New_York")) would return today’s date as seen in a specific time zone, rather than the JVM’s default one.

import java.time.LocalTime;

public class Main {
    public static void main(String[] args) {
        LocalTime now = LocalTime.now();
        System.out.println("Current time: " + now);
    }
}Code language: Java (java)

Explanation:

• LocalTime.now(): Reads the system clock and returns the current time of day, in the JVM’s default time zone, with no date attached.
• Precision: The exact number of digits shown after the seconds varies depending on how much sub-second precision the underlying system clock provides.
• Why no date fields: LocalTime is intentionally limited to hour, minute, second, and nanosecond, making it suitable for representing something like a recurring daily alarm time that should not be tied to a specific calendar day.
• Alternative: now.truncatedTo(ChronoUnit.SECONDS) would drop the nanosecond portion, producing a cleaner HH:mm:ss style output.

import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;

public class Main {
    public static void main(String[] args) {
        LocalDate date = LocalDate.of(2026, 7, 3);
        LocalTime time = LocalTime.of(14, 30, 0);
        LocalDateTime dateTime = LocalDateTime.of(date, time);

        System.out.println("Combined date-time: " + dateTime);
    }
}Code language: Java (java)

Explanation:

• LocalDate.of(2026, 7, 3): Builds a specific calendar date directly from year, month, and day values, rather than reading the system clock.
• LocalTime.of(14, 30, 0): Builds a specific time of day from hour, minute, and second values, using 24-hour notation.
• LocalDateTime.of(date, time): Combines the two separate objects into a single LocalDateTime representing both the date and the time together.
• Trailing seconds omitted: The printed output shows 14:30 rather than 14:30:00, since LocalDateTime‘s default formatting drops the seconds field whenever it is exactly zero.

import java.time.LocalDate;
import java.time.format.TextStyle;
import java.util.Locale;

public class Main {
    public static void main(String[] args) {
        LocalDate date = LocalDate.of(2026, 7, 3);

        System.out.println("Year: " + date.getYear());
        System.out.println("Month: " + date.getMonth().getDisplayName(TextStyle.FULL, Locale.ENGLISH));
        System.out.println("Day of month: " + date.getDayOfMonth());
        System.out.println("Day of week: " + date.getDayOfWeek().getDisplayName(TextStyle.FULL, Locale.ENGLISH));
    }
}Code language: Java (java)

Explanation:

• date.getYear() and date.getDayOfMonth(): Return plain int values for the year and day-of-month fields.
• date.getMonth(): Returns a Month enum constant such as JULY, representing the month independently of any specific year or day.
• getDisplayName(TextStyle.FULL, Locale.ENGLISH): Converts the enum constant into a properly formatted, human-readable name in the specified language, rather than the raw enum constant name.
• date.getDayOfWeek(): Returns a DayOfWeek enum constant, calculated automatically from the date itself rather than being stored separately.

import java.time.Instant;

public class Main {
    public static void main(String[] args) {
        Instant now = Instant.now();
        System.out.println("Current UTC timestamp: " + now);
    }
}Code language: Java (java)

Explanation:

• Instant.now(): Returns the current point in time as measured from the epoch of January 1, 1970, UTC, expressed with nanosecond precision.
• Always UTC: An Instant never carries a local time zone offset. It always represents the same universal moment, regardless of where the code is running.
• Trailing Z: A standard ISO-8601 suffix indicating the timestamp is in UTC, sometimes referred to as “Zulu time”.
• Why this matters: Instant is the preferred type for machine-to-machine timestamps, since it avoids all ambiguity around time zones and daylight saving changes that LocalDateTime alone would not resolve.

import java.time.LocalDate;
import java.time.LocalDateTime;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        LocalDateTime midnight = today.atStartOfDay();

        System.out.println("Midnight today: " + midnight);
    }
}Code language: Java (java)

Explanation:

• today.atStartOfDay(): Combines the given LocalDate with a time of exactly 00:00:00, returning a complete LocalDateTime.
• Why not just use LocalTime.MIDNIGHT manually: atStartOfDay() exists as a convenience method specifically because, in time zones that observe daylight saving changes, the true start of a calendar day is not always exactly midnight local time. Using this method delegates that calculation correctly.
• Alternative: today.atStartOfDay(ZoneId.of("America/New_York")) would return a ZonedDateTime, accounting for that specific zone’s actual start-of-day rules.

import java.time.LocalDate;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        LocalDate twoWeeksLater = today.plusWeeks(2);

        System.out.println("Today: " + today);
        System.out.println("Two weeks from today: " + twoWeeksLater);
    }
}Code language: Java (java)

Explanation:

• today.plusWeeks(2): Adds exactly 14 days to the date, automatically rolling over into the next month or year if the calculation crosses that boundary.
• Immutability: plusWeeks() does not modify today in place. It returns a new LocalDate instance, which is why the result must be captured in its own variable.
• Correct month rollover: Since 2026-07-03 plus 14 days lands on 2026-07-17, well within the same month in this example, but the same call handles crossing into August or beyond just as correctly without any extra logic.
• Alternative: today.plusDays(14) would produce the exact same result, since a week is always defined as 7 days.

import java.time.LocalDate;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        LocalDate tenDaysBefore = today.minusDays(10);
        LocalDate tenDaysAfter = today.plusDays(10);

        System.out.println("10 days before today: " + tenDaysBefore);
        System.out.println("10 days after today: " + tenDaysAfter);
    }
}Code language: Java (java)

Explanation:

• today.minusDays(10): Subtracts 10 days from the date, automatically rolling back into the previous month if needed, as seen here where July 3rd minus 10 days lands in June.
• today.plusDays(10): Adds 10 days forward, staying within the same month in this particular example.
• Both derived from the same today: Since LocalDate is immutable, calling minusDays() and then plusDays() on the same original variable is safe. Neither call affects the value today itself holds.
• Correct calendar awareness: These methods account for varying month lengths automatically, so the same logic works correctly near the end of February, April, or any other month without special-case code.

import java.time.LocalTime;

public class Main {
    public static void main(String[] args) {
        LocalTime now = LocalTime.now();
        LocalTime later = now.plusHours(5).plusMinutes(30);

        System.out.println("Current time: " + now);
        System.out.println("Time after adding 5 hours 30 minutes: " + later);
    }
}Code language: Java (java)

Explanation:

• now.plusHours(5).plusMinutes(30): Chains two separate additions together, since plusHours() returns a new LocalTime that plusMinutes() is immediately called on.
• Immutability: Neither plusHours() nor plusMinutes() changes now itself, which is why now still prints its original, unmodified value afterward.
• Midnight wraparound: If the current time were, for example, 21:00, adding 5 hours 30 minutes would correctly wrap past midnight to 02:30 the next day, though LocalTime itself has no concept of which calendar day that lands on.
• Alternative: now.plus(Duration.ofHours(5).plusMinutes(30)) achieves the same result using a Duration object instead of two chained method calls.

import java.time.Year;
import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("Enter a year: ");
        int year = scanner.nextInt();

        boolean isLeap = Year.isLeap(year);
        System.out.println(year + " is a leap year: " + isLeap);
    }
}Code language: Java (java)

Explanation:

• Year.isLeap(year): A static utility method that applies the full Gregorian leap year rule internally, correctly handling the divisible-by-4, not-divisible-by-100, divisible-by-400 exceptions.
• scanner.nextInt(): Reads the year as an integer directly from user input, which is then passed straight into the leap year check.
• 2024: Divisible by 4 and not divisible by 100, so it correctly qualifies as a leap year under the standard rule.
• Alternative: LocalDate.of(year, 1, 1).isLeapYear() would produce the same result, since LocalDate also exposes an instance-level isLeapYear() method built on the same underlying rule.

import java.time.LocalDateTime;

public class Main {
    public static void main(String[] args) {
        LocalDateTime original = LocalDateTime.of(2026, 7, 3, 14, 30);

        LocalDateTime rolledBack = original.minusYears(3).minusMonths(2).minusDays(15);

        System.out.println("Original: " + original);
        System.out.println("Rolled back: " + rolledBack);
    }
}Code language: Java (java)

Explanation:

• original.minusYears(3): Moves the date back to 2023-07-03T14:30, adjusting only the year field.
• .minusMonths(2): Applied to that result, moving it back further to 2023-05-03T14:30.
• .minusDays(15): Applied last, landing on 2023-04-18T14:30, the final rolled-back value.
• Immutability: Each step in the chain produces a brand new LocalDateTime object rather than modifying the previous one, which is why original still prints its untouched starting value.

import java.time.DayOfWeek;
import java.time.LocalDate;
import java.time.temporal.TemporalAdjusters;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();

        LocalDate nextFriday = today.with(TemporalAdjusters.next(DayOfWeek.FRIDAY));
        LocalDate previousFriday = today.with(TemporalAdjusters.previous(DayOfWeek.FRIDAY));

        System.out.println("Today: " + today);
        System.out.println("Next Friday: " + nextFriday);
        System.out.println("Previous Friday: " + previousFriday);
    }
}Code language: Java (java)

Explanation:

• TemporalAdjusters.next(DayOfWeek.FRIDAY): Produces a rule representing “the next Friday strictly after this date,” which is then applied with with().
• Today already being a Friday: Since next() is strict, it skips today entirely and lands on the following week’s Friday, one week later, rather than returning today’s own date.
• TemporalAdjusters.previous(DayOfWeek.FRIDAY): Works the same way in reverse, finding the most recent Friday strictly before today.
• Alternative: TemporalAdjusters.nextOrSame(DayOfWeek.FRIDAY) and previousOrSame(...) would return today’s own date instead of skipping it, if today already matches the target day of week.

import java.time.LocalDate;
import java.time.temporal.ChronoUnit;

public class Main {
    public static void main(String[] args) {
        LocalDate birthday = LocalDate.of(1998, 11, 20);
        LocalDate today = LocalDate.now();

        long daysBetween = ChronoUnit.DAYS.between(birthday, today);
        System.out.println("Days since birthday: " + daysBetween);
    }
}Code language: Java (java)

Explanation:

• ChronoUnit.DAYS.between(birthday, today): Counts the exact number of whole days between the two dates, correctly accounting for every leap year that falls within the range.
• Argument order: Passing birthday first and today second produces a positive count, since today comes after birthday. Swapping the order would return the same magnitude as a negative number.
• Why not Period here: Period expresses a difference as separate years, months, and days, while ChronoUnit.DAYS.between() collapses the entire gap into one single, easily comparable number.
• Alternative: The same calculation also works for other units by swapping DAYS for WEEKS, MONTHS, or YEARS, though those return the count truncated to whole units rather than the precise day count.

import java.time.LocalDate;
import java.time.Period;

public class Main {
    public static void main(String[] args) {
        LocalDate birthDate = LocalDate.of(1998, 11, 20);
        LocalDate today = LocalDate.now();

        Period age = Period.between(birthDate, today);

        System.out.println("Age: " + age.getYears() + " years, " + age.getMonths() + " months, " + age.getDays() + " days");
    }
}Code language: Java (java)

Explanation:

• Period.between(birthDate, today): Calculates the calendar-aware difference between the two dates, expressed as whole years, whole remaining months, and whole remaining days.
• Why the year count is 27, not 28: Since today falls in July and the birthday is in November, this year’s birthday has not occurred yet, so only 27 full years have actually passed.
• age.getMonths() and age.getDays(): Represent the leftover time past the most recent full year, calculated the same way a person would count “years old, plus a few months and days” by hand.
• Why not ChronoUnit.DAYS here: A single total day count would not distinguish “27 years and a bit” from any other combination of years, months, and days that add up to the same number of total days, which is exactly the breakdown this exercise asks for.

import java.time.LocalDate;
import java.time.Month;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        int currentMonth = today.getMonthValue();
        int remainingMonths = Month.DECEMBER.getValue() - currentMonth;

        System.out.println("Current month: " + today.getMonth());
        System.out.println("Months remaining in " + today.getYear() + ": " + remainingMonths);
    }
}Code language: Java (java)

Explanation:

• today.getMonthValue(): Returns the current month as a plain integer, where January is 1 and December is 12.
• Month.DECEMBER.getValue(): Returns 12, used here instead of a hardcoded literal to make the intent, “the last month of the year”, explicit in the code.
• today.getMonth(): Printed directly, this shows the raw Month enum constant in all capitals, such as JULY, rather than a formatted display name.
• Boundary case: If today fell in December, currentMonth would equal 12, making remainingMonths correctly evaluate to 0.

import java.time.Duration;
import java.time.LocalTime;

public class Main {
    public static void main(String[] args) {
        LocalTime start = LocalTime.of(9, 15, 0);
        LocalTime end = LocalTime.of(17, 45, 30);

        Duration duration = Duration.between(start, end);

        long hours = duration.toHours();
        long minutes = duration.toMinutes() % 60;
        long seconds = duration.getSeconds() % 60;

        System.out.println("Difference: " + hours + " hours, " + minutes + " minutes, " + seconds + " seconds");
    }
}Code language: Java (java)

Explanation:

• Duration.between(start, end): Captures the total elapsed time between the two LocalTime values as a single Duration object, internally stored as a total number of seconds and nanoseconds.
• duration.toHours(): Returns the whole number of hours contained in the duration, truncating any leftover minutes or seconds.
• duration.toMinutes() % 60: toMinutes() alone would return the total duration in minutes, 510 in this case, so the % 60 isolates just the leftover minutes beyond the full hours already counted.
• duration.getSeconds() % 60: Similarly isolates the leftover seconds beyond the full minutes already accounted for.

import java.time.Instant;

public class Main {
    public static void main(String[] args) {
        Instant now = Instant.now();
        long secondsSinceEpoch = now.getEpochSecond();

        System.out.println("Seconds since Unix Epoch: " + secondsSinceEpoch);
    }
}Code language: Java (java)

Explanation:

• Instant.now(): Captures the current moment as an Instant, internally represented as a count of seconds and nanoseconds relative to the epoch.
• now.getEpochSecond(): Extracts just the whole-seconds portion of that internal representation, discarding the nanosecond fraction.
• Why this number is useful: A Unix timestamp is a single, unambiguous integer that is easy to store, compare, and transmit between systems, which is why so many APIs and databases use it as their default timestamp format.
• Alternative: now.toEpochMilli() returns the same underlying value with millisecond precision instead, which is the format many JavaScript-based systems expect.

import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;

public class Main {
    public static void main(String[] args) {
        long unixTimestamp = 1719924800L;

        LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.ofEpochSecond(unixTimestamp), ZoneId.of("UTC"));

        System.out.println("Converted date-time: " + dateTime);
    }
}Code language: Java (java)

Explanation:

• Instant.ofEpochSecond(unixTimestamp): Reconstructs the exact universal moment the raw number represents, the reverse operation of getEpochSecond() from the previous exercise.
• ZoneId.of("UTC"): Specifies which time zone to interpret the instant in when converting it into calendar fields. Since Unix timestamps are inherently UTC-based, using UTC here keeps the conversion accurate.
• LocalDateTime.ofInstant(instant, zoneId): Combines the universal instant with the chosen time zone to produce a readable calendar date and time.
• Different zone, different result: Passing a different ZoneId, such as ZoneId.of("America/New_York"), would produce a different local date and time from the exact same underlying instant.

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;

public class Main {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd/MM/yyyy");

        String formatted = today.format(formatter);
        System.out.println("Formatted date: " + formatted);
    }
}Code language: Java (java)

Explanation:

• DateTimeFormatter.ofPattern("dd/MM/yyyy"): Defines a custom text layout using pattern letters, where dd is the zero-padded day, MM is the zero-padded month, and yyyy is the four-digit year.
• Case sensitivity matters: MM (uppercase) means month, while mm (lowercase) means minutes. Mixing these up is a common source of formatting bugs.
• today.format(formatter): Applies the pattern to the date, producing a plain String laid out exactly according to the formatter’s rules.
• Reusability: The same formatter instance can be reused to format any number of different LocalDate values consistently, rather than building a new formatter each time.

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class Main {
    public static void main(String[] args) {
        LocalDateTime now = LocalDateTime.now();
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("EEEE, dd MMMM yyyy hh:mm a", Locale.ENGLISH);

        String formatted = now.format(formatter);
        System.out.println("Formatted: " + formatted);
    }
}Code language: Java (java)

Explanation:

• EEEE: Renders the full weekday name, such as Friday, rather than an abbreviation like Fri.
• MMMM: Renders the full month name, such as July, following the same full-versus-abbreviated pattern convention as the weekday.
• hh:mm a: hh is the 12-hour clock hour, mm is minutes, and the literal a inserts the localized AM or PM marker at the end.
• Locale.ENGLISH: Forces the weekday and month names to render in English, so the output stays consistent even if this code runs on a system configured with a different default locale.

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;

public class Main {
    public static void main(String[] args) {
        String dateString = "2026-12-25";
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");

        LocalDate date = LocalDate.parse(dateString, formatter);
        System.out.println("Parsed date: " + date);
    }
}Code language: Java (java)

Explanation:

• DateTimeFormatter.ofPattern("yyyy-MM-dd"): Describes the exact shape the input text must follow in order to be parsed successfully.
• LocalDate.parse(dateString, formatter): Reads the string according to that pattern and constructs a real LocalDate object from it.
• Result type: Once parsed, date behaves exactly like any other LocalDate, whether it was built from a string, from now(), or from LocalDate.of().
• Alternative: Since "2026-12-25" already matches the default ISO-8601 format, LocalDate.parse(dateString) without any formatter would also work here. An explicit formatter becomes necessary once the input string uses a non-standard layout.

import java.time.OffsetDateTime;

public class Main {
    public static void main(String[] args) {
        String dateTimeString = "2026-07-03T15:30:00-05:00";

        OffsetDateTime offsetDateTime = OffsetDateTime.parse(dateTimeString);
        System.out.println("Parsed: " + offsetDateTime);
        System.out.println("Offset: " + offsetDateTime.getOffset());
    }
}Code language: Java (java)

Explanation:

• OffsetDateTime.parse(dateTimeString): Parses both the local date-time portion and the trailing -05:00 offset in one step, since the string already follows the default ISO-8601 layout OffsetDateTime expects.
• Why not LocalDateTime: Parsing this same string as a LocalDateTime would fail, since LocalDateTime has no field to hold the offset information at the end of the string.
• offsetDateTime.getOffset(): Extracts just the -05:00 portion as a standalone ZoneOffset object, separate from the date and time fields.
• Seconds dropped in output: The printed result shows 15:30 rather than 15:30:00, since the default formatting omits the seconds field whenever it is exactly zero, the same behavior seen with LocalDateTime.

import java.time.LocalTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class Main {
    public static void main(String[] args) {
        LocalTime now = LocalTime.now();

        DateTimeFormatter military = DateTimeFormatter.ofPattern("HH:mm:ss");
        DateTimeFormatter standard = DateTimeFormatter.ofPattern("hh:mm:ss a", Locale.ENGLISH);

        System.out.println("24-hour format: " + now.format(military));
        System.out.println("12-hour format: " + now.format(standard));
    }
}Code language: Java (java)

Explanation:

• "HH:mm:ss": Uses the 24-hour hour field, so 3:45 PM prints as 15:45:22 with no AM/PM marker needed.
• "hh:mm:ss a": Uses the 12-hour hour field paired with the a marker, so the same moment prints as 03:45:22 PM instead.
• Same underlying now, two formatters: Both formatted strings describe the exact same point in time, just laid out according to two different pattern rules.
• Locale.ENGLISH: Ensures the AM/PM marker renders in English, since some locales use different text or symbols for that marker.

import java.time.LocalDate;
import java.time.format.DateTimeParseException;

public class Main {
    public static void main(String[] args) {
        String badDateString = "2026-13-40";

        try {
            LocalDate date = LocalDate.parse(badDateString);
            System.out.println("Parsed date: " + date);
        } catch (DateTimeParseException e) {
            System.out.println("Error: Invalid date format - " + e.getMessage());
        }
    }
}Code language: Java (java)

Explanation:

• LocalDate.parse(badDateString): Attempts to interpret "2026-13-40" as an ISO date, but fails as soon as it validates the month field.
• DateTimeParseException: Thrown specifically for parsing failures, distinct from other exceptions, making it easy to catch parsing problems without accidentally catching unrelated bugs.
• Why month fails first: The parser validates each field as it goes, so it reports the invalid month value 13 immediately, without ever getting to check whether day 40 would have been valid too.
• e.getMessage(): Returns a detailed, specific explanation of exactly what went wrong and where, which is far more useful for debugging than a generic failure message.

import java.time.ZonedDateTime;
import java.time.ZoneId;

public class Main {
    public static void main(String[] args) {
        ZonedDateTime newYorkTime = ZonedDateTime.now(ZoneId.of("America/New_York"));
        ZonedDateTime londonTime = ZonedDateTime.now(ZoneId.of("Europe/London"));

        System.out.println("New York time: " + newYorkTime);
        System.out.println("London time: " + londonTime);
    }
}Code language: Java (java)

Explanation:

• ZoneId.of("America/New_York"): Represents a named geographic region with its own complete set of historical and current offset rules, including daylight saving transitions.
• ZonedDateTime.now(zoneId): Captures the current instant and immediately renders it in local date and time fields for that specific zone.
• Bracketed zone name in output: The trailing [America/New_York] in the printed result distinguishes a ZonedDateTime from an OffsetDateTime, showing which named zone’s rules were actually applied.
• Why the offsets differ: Both lines represent the exact same real-world moment, but America/New_York and Europe/London have different UTC offsets, so their local time-of-day fields naturally differ too.

import java.time.ZoneId;
import java.util.Set;

public class Main {
    public static void main(String[] args) {
        Set<String> zoneIds = ZoneId.getAvailableZoneIds();
        System.out.println("Total available zone IDs: " + zoneIds.size());

        zoneIds.stream()
               .sorted()
               .limit(5)
               .forEach(System.out::println);
    }
}Code language: Java (java)

Explanation:

• ZoneId.getAvailableZoneIds(): Returns every zone name the JVM currently recognizes, sourced from its built-in copy of the IANA time zone database.
• zoneIds.size(): Reports the total number of recognized zone names, which changes slightly between JDK releases as the underlying time zone database is updated.
• .sorted(): Since a Set has no inherent order, sorting the stream alphabetically before printing makes the sample output predictable and easy to read.
• .limit(5): Restricts the printed sample to just the first five entries alphabetically, since printing all several hundred zone names at once would be excessive for a simple demonstration.

import java.time.DayOfWeek;
import java.time.LocalDate;

public class Main {
    public static void main(String[] args) {
        LocalDate date = LocalDate.of(2026, 2, 13);

        boolean isFridayThe13th = date.getDayOfMonth() == 13 && date.getDayOfWeek() == DayOfWeek.FRIDAY;

        System.out.println(date + " is Friday the 13th: " + isFridayThe13th);
    }
}Code language: Java (java)

Explanation:

• date.getDayOfMonth() == 13: Checks the numeric day-of-month field directly against the literal value 13.
• date.getDayOfWeek() == DayOfWeek.FRIDAY: Compares the computed weekday enum constant against FRIDAY, using == since enum constants are singleton instances that can be compared safely this way.
• &&: Requires both conditions to hold simultaneously, since a date could be the 13th on a different weekday, or a Friday on a different day of the month, without qualifying.
• LocalDate.of(2026, 2, 13): This particular date does land on a Friday, so both conditions are satisfied and the result is true.

import java.time.DayOfWeek;
import java.time.LocalDate;
import java.time.YearMonth;

public class Main {
    public static void main(String[] args) {
        int year = 2026;
        int month = 7;

        YearMonth yearMonth = YearMonth.of(year, month);
        LocalDate date = yearMonth.atDay(1);

        System.out.println("Mondays in " + yearMonth + ":");
        while (date.getMonthValue() == month) {
            if (date.getDayOfWeek() == DayOfWeek.MONDAY) {
                System.out.println(date);
            }
            date = date.plusDays(1);
        }
    }
}Code language: Java (java)

Explanation:

• YearMonth.of(year, month): Represents a specific month without needing a particular day, useful as an anchor for month-wide calculations like this one.
• yearMonth.atDay(1): Produces the first calendar date of that month, used here as the starting point for the scan.
• while (date.getMonthValue() == month): Keeps the loop going only while date is still within the target month, naturally stopping once it rolls over into the next one.
• date.plusDays(1): Advances the scan one day at a time, checking every single date in the month for a match against DayOfWeek.MONDAY.

import java.time.LocalDate;
import java.time.Month;

public class Main {
    public static void main(String[] args) {
        int year = 2028;

        for (Month month : Month.values()) {
            int length = LocalDate.of(year, month, 1).lengthOfMonth();
            System.out.println(month + ": " + length + " days");
        }
    }
}Code language: Java (java)

Explanation:

• Month.values(): Returns all twelve Month enum constants in calendar order, from JANUARY through DECEMBER, ready to loop over directly.
• LocalDate.of(year, month, 1): Builds a date on the first of each month for the target year. The day value itself does not affect the resulting month length, only the year and month do.
• lengthOfMonth(): Returns the correct number of days for that specific month and year, automatically returning 29 for February in a leap year and 28 otherwise.
• 2028 as a leap year: Since 2028 is divisible by 4 and not by 100, February correctly reports 29 days in the output, confirming the leap year logic is applied automatically.

import java.time.ZoneId;
import java.time.ZoneOffset;
import java.time.ZonedDateTime;

public class Main {
    public static void main(String[] args) {
        ZonedDateTime tokyoTime = ZonedDateTime.now(ZoneId.of("Asia/Tokyo"));
        ZonedDateTime chicagoTime = ZonedDateTime.now(ZoneId.of("America/Chicago"));

        ZoneOffset tokyoOffset = tokyoTime.getOffset();
        ZoneOffset chicagoOffset = chicagoTime.getOffset();

        int differenceInSeconds = tokyoOffset.getTotalSeconds() - chicagoOffset.getTotalSeconds();
        int differenceInHours = differenceInSeconds / 3600;

        System.out.println("Tokyo time: " + tokyoTime);
        System.out.println("Chicago time: " + chicagoTime);
        System.out.println("Difference: " + differenceInHours + " hours");
    }
}Code language: Java (java)

Explanation:

• ZonedDateTime.now(ZoneId.of(...)): Captures the current moment as seen locally in each named zone, including whichever offset is currently active for that location.
• getOffset(): Retrieves just the current UTC offset for that zone, such as +09:00 for Tokyo, which does not observe daylight saving, or -05:00 for Chicago during its daylight saving period.
• tokyoOffset.getTotalSeconds() - chicagoOffset.getTotalSeconds(): Subtracts the two offsets, measured in total seconds, giving the raw difference before converting to a more readable unit.
• differenceInSeconds / 3600: Converts the raw second difference into whole hours, producing the final, easily understood hour gap between the two cities.