Loading…

easyMath GeometrySometimes asked

Day of the Programmer

Q: How do you solve Day of the Programmer using the Month Accumulation — Count Days Across Months approach?

When to use it: A clean, general baseline: build month lengths and walk forward until you hit day 256. Mention it to show the general technique before specialising. This version generalises to any day-of-year, not just 256, by walking the calendar. **Building the month table.** The only month whose length varies is February. Decide it first: 15 days if `year == 1918`, otherwise 29 if the era's leap rule fires (Julian `% 4` for ≤ 1917, Gregorian `% 400 / % 4 / % 100` for ≥ 1919), otherwise 28. Plug that into the standard `[31, feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]`. **Walking to the target day.** Start `remaining = 256`. For each month, if `remaining` is larger than that month's length, the target lies further on — subtract the month and move to the next. Stop the moment `remaining <= days[month]`: the target falls inside this month, and `remaining` is now the day number. This is the same logic a calendar library uses to convert a day-of-year into a date. **Why it lands in September.** January through August sum to 243 (common), 244 (leap), or 230 (1918). In every case `remaining` after August is between 1 and 30, so the loop halts on the September entry — confirming the closed-form shortcut the optimal approach uses. **Why mention it.** It is dependable and obviously correct, and it makes the September observation concrete rather than asserted. The optimal version simply skips the walk because we know the answer is always September. Time complexity: O(1). Space complexity: O(1).

Q: How do you solve Day of the Programmer using the Direct Branch — September Closed Form (Optimal) approach?

When to use it: The tight answer. Since the 256th day is always in September, skip the walk and branch straight to the day. Since the target never leaves September, collapse the whole calendar into three printed strings. **Why September is guaranteed.** January through August is `31+28+31+30+31+30+31+31 = 243` days in a common year and `244` in a leap year. Day 256 is therefore `256 − 243 = 13` (common) or `256 − 244 = 12` (leap) of September. In 1918, those eight months total `230` because February held only 15 days, so day 256 is `256 − 230 = 26` of September. **The leap branch by era.** For years up to 1917 the calendar is Julian: a year is a leap year exactly when `year % 4 == 0`, with no century exceptions. For 1919 onward it is Gregorian: a leap year is divisible by 400, or divisible by 4 but not by 100. Applying the wrong rule near century boundaries (1800, 1900) is the most common silent error — under Julian, 1800 is a leap year; under Gregorian it would not be. **The 1918 special case.** This single year is neither cleanly Julian nor Gregorian for our purposes — its February was truncated to 15 days. Hardcoding `26.09.1918` is clearer and safer than trying to fold it into the leap logic. **Assembling the output.** Everything reduces to choosing `12` or `13` for the day, then appending `.09.` and the year. Zero-padding matters: the format is `dd.mm.yyyy`, so the month is always `09`, never `9`. Time complexity: O(1). Space complexity: O(1).

Math & Number Theory · 31 of 36 · 8 min

Marie invented a calendar where the Day of the Programmer falls on the 256th day of the year. Given a year year in the inclusive range 1700 to 2700, return the date of the 256th day in the format dd.mm.yyyy.

The country used the Julian calendar through 1917, then switched to the Gregorian calendar. The transition happened in 1918, when the day after January 31 was February 14 — that year February had only 15 days.

In plain English

The 256th day of the year is what we want as a calendar date. Days January through August total 243 in a common year and 244 in a leap year, so the 256th day lands on September 13 or September 12 respectively. The 1918 transition removed 13 days from February, shifting that year's 256th day to September 26. Everything reduces to: which leap rule applies, and is this the transition year?

Examples

Example 1

Input: year = 2017
Output: 13.09.2017
Note: Gregorian, 2017 is not divisible by 4 → common year. Jan–Aug = 243 days, so day 256 is September 13.

Example 2

Input: year = 2016
Output: 12.09.2016
Note: Gregorian, 2016 divisible by 4 and not by 100 → leap. Jan–Aug = 244 days, so day 256 is September 12.

Example 3

Input: year = 1918
Output: 26.09.1918
Note: Transition year: February lost 13 days (only 15 days), so Jan–Aug = 230 days and day 256 is September 26.

Constraints

1700 ≤ year ≤ 2700
Julian leap year (year ≤ 1917): year divisible by 4
Gregorian leap year (year ≥ 1919): divisible by 400, or divisible by 4 and not by 100
1918 is the transition year: February has 15 days
Output format is exactly dd.mm.yyyy with zero-padding

Clarifying questions4First question: Which calendar applies to which years?Explore questions

Q1.Which calendar applies to which years?
Julian for years up to and including 1917, Gregorian for 1919 and later. 1918 is the one-time transition year with a shortened February.
Q2.What exactly happened in 1918?
The day after 31 January 1918 was 14 February 1918 — 13 dates were skipped, so that February had only 15 days and the 256th day became 26.09.1918.
Q3.Do the Gregorian century rules apply to Julian years?
No. Under Julian, every year divisible by 4 is a leap year — the % 100 and % 400 exceptions are Gregorian-only. Mixing them up is the classic bug.
Q4.How should the date be formatted?
dd.mm.yyyy with zero-padded day and month, e.g. 12.09.2016 and 26.09.1918.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Find the 256th day of a given year and print it as dd.mm.yyyy. The 256th day is always in September; the only thing that moves it is February's length. Use the Julian leap rule (year % 4 == 0) for years up to 1917, the Gregorian rule (divisible by 400, or by 4 but not 100) from 1919 on, and treat 1918 specially because that February lost 13 days. The answer is 12.09 in a leap year, 13.09 in a common year, and 26.09 in 1918.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Whether you can encode era-dependent leap-year rules correctly, remember the 1918 Julian-to-Gregorian transition that deleted 13 days, and format the result as a fixed-width date — careful branching, not algorithmic depth.

Where candidates slip

Applying the Gregorian % 100 / % 400 exceptions to pre-1918 (Julian) years, or forgetting 1918 entirely and printing 13.09.1918 instead of 26.09.1918.

How to stand out

Separate the three regimes out loud — Julian (≤1917), the 1918 transition, Gregorian (≥1919) — and explain why only February's length can shift the 256th day.

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Month Accumulation — Count Days Across Months	`O(1)`	`O(1)`	A clean, general baseline: build month lengths and walk forward until you hit day 256. Mention it to show the general technique before specialising.	Read
2	Direct Branch — September Closed Form (Optimal)Optimal	`O(1)`	`O(1)`	The tight answer. Since the 256th day is always in September, skip the walk and branch straight to the day.	Read

Interactive decision treeInteractiveChoose the right approachFollow the branches and learn why each constraint changes the solution.First decision previewFind the 256th dayyear == 1918?YesNoExplore the full tree

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Month Accumulation — Count Days Across Months

TimeO(1)SpaceO(1)

A clean, general baseline: build month lengths and walk forward until you hit day 256. Mention it to show the general technique before specialising.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

Build the 12 month lengths for this specific year, getting February right via the era's leap rule (and the 1918 special case).

2Hint 2Explore hint

Walk month by month, subtracting each month's length from a running 'remaining = 256' until remaining no longer exceeds the current month.

3Hint 3Explore hint

When the loop stops, `remaining` is the day-of-month and the current month index gives the month. Format as dd.mm.yyyy.

A · Core idea

This version generalises to any day-of-year, not just 256, by walking the calendar.

Building the month table. The only month whose length varies is February. Decide it first: 15 days if year == 1918, otherwise 29 if the era's leap rule fires (Julian % 4 for ≤ 1917, Gregorian % 400 / % 4 / % 100 for ≥ 1919), otherwise 28. Plug that into the standard [31, feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31].

Walking to the target day. Start remaining = 256. For each month, if remaining is larger than that month's length, the target lies further on — subtract the month and move to the next. Stop the moment remaining <= days[month]: the target falls inside this month, and remaining is now the day number. This is the same logic a calendar library uses to convert a day-of-year into a date.

Why it lands in September. January through August sum to 243 (common), 244 (leap), or 230 (1918). In every case remaining after August is between 1 and 30, so the loop halts on the September entry — confirming the closed-form shortcut the optimal approach uses.

Why mention it. It is dependable and obviously correct, and it makes the September observation concrete rather than asserted. The optimal version simply skips the walk because we know the answer is always September.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

year = 1918

Subtracting months down to day 256

How to read it:Each month peels off until the remaining count fits — it always stops in September.

Rendering diagram…

Final result26.09.1918

C · Code with teaching comments

Reference implementation previewpublic String dayOfProgrammer(int year) { int feb; if (year == 1918) { feb = 15; // transition year } else if (year < 1918) {Explore the full code

solution.javaJava

Month Accumulation — Count Days Across Months — reference

4 teaching notes

1
public String dayOfProgrammer(int year) {
2
    int feb;
3
    // Transition year first — its February of 15 days overrides every leap rule.
4
    if (year == 1918) {
5
        feb = 15;                                  // transition year
6
    } else if (year < 1918) {
7
        feb = (year % 4 == 0) ? 29 : 28;           // Julian
8
    } else {
9
        boolean leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);
10
        feb = leap ? 29 : 28;                      // Gregorian
11
    }
12
    int[] days = {31, feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
13
    int remaining = 256, month = 0;
14
    // Subtract whole months until day 256 lands inside the current month.
15
    while (remaining > days[month]) {
16
        remaining -= days[month];
17
        month++;
18
    }
19
    // Zero-pad day and month; month + 1 converts the 0-based index to a calendar month.
20
    return String.format("%02d.%02d.%d", remaining, month + 1, year);
21
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.21 lines

D · Why it works and complexityO(1) timeO(1) spaceOpen the invariant and proofExplore the proof

Converting a day-of-year to a date is 'subtract month lengths until the day fits'. Getting February right per era is the only hard part; the walk itself is mechanical.

ComplexityO(1) time, O(1) space — At most 12 months are scanned regardless of input, and a fixed-size array of month lengths is used — constant time and space.

E · Edge cases and pitfalls3Using the Gregorian leap rule for pre-1918 years — Julian has no % 100 / % 400 exceptions.Explore edge cases

Pitfalls

Using the Gregorian leap rule for pre-1918 years — Julian has no % 100 / % 400 exceptions.
Setting February to 28 or 29 in 1918 instead of 15.
Comparing with `>=` instead of `>` in the loop, landing on the wrong month boundary.

03.2

Approach 2 of 2 · Optimal

Direct Branch — September Closed Form (Optimal)

TimeO(1)SpaceO(1)

The tight answer. Since the 256th day is always in September, skip the walk and branch straight to the day.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

You already know Jan–Aug = 243 (common) / 244 (leap), so day 256 is September 13 or 12 — no month walk needed.

2Hint 2Explore hint

Branch the leap decision by era: Julian (% 4) for ≤ 1917, Gregorian (% 400, % 4, % 100) for ≥ 1919.

3Hint 3Explore hint

Handle 1918 as a hardcoded 26.09.1918. Everything else is '12 or 13, dot 09, dot year'.

A · Core idea

Since the target never leaves September, collapse the whole calendar into three printed strings.

Why September is guaranteed. January through August is 31+28+31+30+31+30+31+31 = 243 days in a common year and 244 in a leap year. Day 256 is therefore 256 − 243 = 13 (common) or 256 − 244 = 12 (leap) of September. In 1918, those eight months total 230 because February held only 15 days, so day 256 is 256 − 230 = 26 of September.

The leap branch by era. For years up to 1917 the calendar is Julian: a year is a leap year exactly when year % 4 == 0, with no century exceptions. For 1919 onward it is Gregorian: a leap year is divisible by 400, or divisible by 4 but not by 100. Applying the wrong rule near century boundaries (1800, 1900) is the most common silent error — under Julian, 1800 is a leap year; under Gregorian it would not be.

The 1918 special case. This single year is neither cleanly Julian nor Gregorian for our purposes — its February was truncated to 15 days. Hardcoding 26.09.1918 is clearer and safer than trying to fold it into the leap logic.

Assembling the output. Everything reduces to choosing 12 or 13 for the day, then appending .09. and the year. Zero-padding matters: the format is dd.mm.yyyy, so the month is always 09, never 9.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

year = 1800

Interactive diagram

Three regimes, three day numbers

transition?

Active call / nodeSupporting contextReturned stateNot active

The era picks the leap rule; the leap rule picks 12 vs 13; 1918 is its own answer.

Final result12.09.1800

C · Code with teaching comments

solution.javaJava

Direct Branch — September Closed Form (Optimal) — optimal

4 teaching notes

1
public String dayOfProgrammer(int year) {
2
    // Transition year is its own answer — check it before any leap logic.
3
    if (year == 1918) {
4
        return "26.09.1918";                       // transition year
5
    }
6
    boolean leap;
7
    if (year < 1918) {
8
        leap = year % 4 == 0;                      // Julian
9
    } else {
10
        leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);  // Gregorian
11
    }
12
    // Day 12 in a leap year, 13 otherwise; month is always September.
13
    return (leap ? "12" : "13") + ".09." + year;
14
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.14 lines

D · Why it works and complexityO(1) timeO(1) spaceOpen the invariant and proofExplore the proof

The 256th day can only move when February's length moves, and February only touches the Jan–Aug prefix. That is why three printed strings cover every year in range — the rest is choosing the correct leap rule for the era.

ComplexityO(1) time, O(1) space — A couple of comparisons and a string build — constant work, constant space, independent of the year.

E · Edge cases and pitfalls6year = 1900 — Julian (≤ 1917): 1900 % 4 == 0 → leap → 12.09.1900. Under Gregorian it would be common — the era matters.Explore edge cases

Edge cases handled

year = 1900Julian (≤ 1917): 1900 % 4 == 0 → leap → 12.09.1900. Under Gregorian it would be common — the era matters.
year = 2000Gregorian: 2000 % 400 == 0 → leap → 12.09.2000. The 400-exception keeps it a leap year.
year = 1917Last Julian year: 1917 % 4 != 0 → common → 13.09.1917.

Pitfalls

Forgetting 1918 entirely and printing 13.09.1918 instead of 26.09.1918.
Applying Gregorian century rules to years ≤ 1917 (e.g. wrongly calling 1900 common).
Dropping the zero-pad and printing 13.9.2017 instead of 13.09.2017.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Editable code previewpublic String dayOfProgrammer(int year) { if (year == 1918) { return "26.09.1918"; // transition year } boolean leap;Explore the playground

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Wrong leap rule for the era

Before 1918 the calendar is Julian: every multiple of 4 is a leap year. Applying Gregorian century exceptions wrongly marks 1700, 1800, 1900 as common.

Explore the code comparison

Don't write this

boolean leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);  // wrong for year <= 1917

Write this instead

boolean leap = (year < 1918)
    ? year % 4 == 0
    : year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);

Missing the 1918 transition

1918 deleted 13 days from February, so the 256th day is 26.09, not the usual 13.09. Folding it into leap logic silently gets it wrong.

Explore the code comparison

Don't write this

leap = year % 400 == 0 or (year % 4 == 0 and year % 100 != 0)
return f"{'12' if leap else '13'}.09.{year}"   # gives 13.09.1918

Write this instead

if year == 1918:
    return "26.09.1918"
# ... normal leap logic for every other year

Unpadded date format

The required format is dd.mm.yyyy. September must print as 09 and the day as two digits; 13.9.2017 fails the checker.

Explore the code comparison

Don't write this

return f"{day}.{9}.{year}"        # 13.9.2017

Write this instead

return f"{day:02d}.09.{year}"     # 13.09.2017

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Branch on the calendar, then closed-form the date

Code pattern to memorize

if year == 1918: return "26.09.1918"
if year < 1918:  leap = (year % 4 == 0)                  # Julian
else:            leap = (year % 400 == 0) or (year % 4 == 0 and year % 100 != 0)  # Gregorian
return ("12" if leap else "13") + ".09." + str(year)

Rules to remember

11918 is the transition year and the trap: switching from Julian to Gregorian deleted 13 days that February, so the 256th day is 26.09.1918. Hardcode it.
2Years ≤ 1917 use the Julian rule — leap iff year % 4 == 0. The % 100 and % 400 exceptions do not exist yet.
3Years ≥ 1919 use the Gregorian rule — leap iff divisible by 400, or divisible by 4 but not by 100.
4The 256th day is always in September for normal years: Jan–Aug is 243 days common / 244 leap, so day 256 is the 13th or 12th of September.
5Output is fixed-width dd.mm.yyyy — zero-pad day and month (26.09.1918), never 26.9.1918.

Use this pattern when

Date / calendar arithmetic with calendar-system changes
A fixed day-of-year mapped to a concrete date
Leap-year reasoning where the rule depends on the era
A small set of regimes you can branch over in O(1)

Choose another pattern when

Arbitrary date differences across many years → use a date library or epoch days
Time zones / hours / minutes involved → far beyond integer day counting
You must handle every historical calendar quirk → this problem only spans one transition
The day-of-year is an input that varies → loop over months instead of hardcoding September

Interview takeaway

Calendar problems are branch-then-count: pick the right leap rule for the era, remember the one-off transition year, then map the day-of-year to a date. Day of the Programmer collapses to three cases because the 256th day never leaves September.

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Transferable patternBranch-then-count calendar arithmetic. Identify which regime (era, special year) applies, apply that regime's rule, then map the day-of-year to a concrete date. Day of the Programmer needs only three cases because the answer never leaves September.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Same pattern

←

Sum of Digits (Digital Root)

Continue · Next problem

Drawing Book

easyMath GeometrySometimes asked

Day of the Programmer

Math & Number Theory · 31 of 36 · 8 min

In plain English

Examples

Example 1

Input: year = 2017
Output: 13.09.2017
Note: Gregorian, 2017 is not divisible by 4 → common year. Jan–Aug = 243 days, so day 256 is September 13.

Example 2

Input: year = 2016
Output: 12.09.2016
Note: Gregorian, 2016 divisible by 4 and not by 100 → leap. Jan–Aug = 244 days, so day 256 is September 12.

Example 3

Input: year = 1918
Output: 26.09.1918
Note: Transition year: February lost 13 days (only 15 days), so Jan–Aug = 230 days and day 256 is September 26.

Constraints

1700 ≤ year ≤ 2700
Julian leap year (year ≤ 1917): year divisible by 4
Gregorian leap year (year ≥ 1919): divisible by 400, or divisible by 4 and not by 100
1918 is the transition year: February has 15 days
Output format is exactly dd.mm.yyyy with zero-padding

Clarifying questions4First question: Which calendar applies to which years?Explore questions

Q1.Which calendar applies to which years?
Julian for years up to and including 1917, Gregorian for 1919 and later. 1918 is the one-time transition year with a shortened February.
Q2.What exactly happened in 1918?
The day after 31 January 1918 was 14 February 1918 — 13 dates were skipped, so that February had only 15 days and the 256th day became 26.09.1918.
Q3.Do the Gregorian century rules apply to Julian years?
No. Under Julian, every year divisible by 4 is a leap year — the % 100 and % 400 exceptions are Gregorian-only. Mixing them up is the classic bug.
Q4.How should the date be formatted?
dd.mm.yyyy with zero-padded day and month, e.g. 12.09.2016 and 26.09.1918.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Where candidates slip

Applying the Gregorian % 100 / % 400 exceptions to pre-1918 (Julian) years, or forgetting 1918 entirely and printing 13.09.1918 instead of 26.09.1918.

How to stand out

Separate the three regimes out loud — Julian (≤1917), the 1918 transition, Gregorian (≥1919) — and explain why only February's length can shift the 256th day.

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Month Accumulation — Count Days Across Months	`O(1)`	`O(1)`	A clean, general baseline: build month lengths and walk forward until you hit day 256. Mention it to show the general technique before specialising.	Read
2	Direct Branch — September Closed Form (Optimal)Optimal	`O(1)`	`O(1)`	The tight answer. Since the 256th day is always in September, skip the walk and branch straight to the day.	Read

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Month Accumulation — Count Days Across Months

TimeO(1)SpaceO(1)

A clean, general baseline: build month lengths and walk forward until you hit day 256. Mention it to show the general technique before specialising.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

Build the 12 month lengths for this specific year, getting February right via the era's leap rule (and the 1918 special case).

2Hint 2Explore hint

Walk month by month, subtracting each month's length from a running 'remaining = 256' until remaining no longer exceeds the current month.

3Hint 3Explore hint

When the loop stops, `remaining` is the day-of-month and the current month index gives the month. Format as dd.mm.yyyy.

A · Core idea

This version generalises to any day-of-year, not just 256, by walking the calendar.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

year = 1918

Subtracting months down to day 256

How to read it:Each month peels off until the remaining count fits — it always stops in September.

Rendering diagram…

Final result26.09.1918

C · Code with teaching comments

Reference implementation previewpublic String dayOfProgrammer(int year) { int feb; if (year == 1918) { feb = 15; // transition year } else if (year < 1918) {Explore the full code

solution.javaJava

Month Accumulation — Count Days Across Months — reference

4 teaching notes

1
public String dayOfProgrammer(int year) {
2
    int feb;
3
    // Transition year first — its February of 15 days overrides every leap rule.
4
    if (year == 1918) {
5
        feb = 15;                                  // transition year
6
    } else if (year < 1918) {
7
        feb = (year % 4 == 0) ? 29 : 28;           // Julian
8
    } else {
9
        boolean leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);
10
        feb = leap ? 29 : 28;                      // Gregorian
11
    }
12
    int[] days = {31, feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
13
    int remaining = 256, month = 0;
14
    // Subtract whole months until day 256 lands inside the current month.
15
    while (remaining > days[month]) {
16
        remaining -= days[month];
17
        month++;
18
    }
19
    // Zero-pad day and month; month + 1 converts the 0-based index to a calendar month.
20
    return String.format("%02d.%02d.%d", remaining, month + 1, year);
21
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.21 lines

D · Why it works and complexityO(1) timeO(1) spaceOpen the invariant and proofExplore the proof

Converting a day-of-year to a date is 'subtract month lengths until the day fits'. Getting February right per era is the only hard part; the walk itself is mechanical.

ComplexityO(1) time, O(1) space — At most 12 months are scanned regardless of input, and a fixed-size array of month lengths is used — constant time and space.

E · Edge cases and pitfalls3Using the Gregorian leap rule for pre-1918 years — Julian has no % 100 / % 400 exceptions.Explore edge cases

Pitfalls

Using the Gregorian leap rule for pre-1918 years — Julian has no % 100 / % 400 exceptions.
Setting February to 28 or 29 in 1918 instead of 15.
Comparing with `>=` instead of `>` in the loop, landing on the wrong month boundary.

03.2

Approach 2 of 2 · Optimal

Direct Branch — September Closed Form (Optimal)

TimeO(1)SpaceO(1)

The tight answer. Since the 256th day is always in September, skip the walk and branch straight to the day.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

You already know Jan–Aug = 243 (common) / 244 (leap), so day 256 is September 13 or 12 — no month walk needed.

2Hint 2Explore hint

Branch the leap decision by era: Julian (% 4) for ≤ 1917, Gregorian (% 400, % 4, % 100) for ≥ 1919.

3Hint 3Explore hint

Handle 1918 as a hardcoded 26.09.1918. Everything else is '12 or 13, dot 09, dot year'.

A · Core idea

Since the target never leaves September, collapse the whole calendar into three printed strings.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

year = 1800

Interactive diagram

Three regimes, three day numbers

transition?

Active call / nodeSupporting contextReturned stateNot active

The era picks the leap rule; the leap rule picks 12 vs 13; 1918 is its own answer.

Final result12.09.1800

C · Code with teaching comments

solution.javaJava

Direct Branch — September Closed Form (Optimal) — optimal

4 teaching notes

1
public String dayOfProgrammer(int year) {
2
    // Transition year is its own answer — check it before any leap logic.
3
    if (year == 1918) {
4
        return "26.09.1918";                       // transition year
5
    }
6
    boolean leap;
7
    if (year < 1918) {
8
        leap = year % 4 == 0;                      // Julian
9
    } else {
10
        leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);  // Gregorian
11
    }
12
    // Day 12 in a leap year, 13 otherwise; month is always September.
13
    return (leap ? "12" : "13") + ".09." + year;
14
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.14 lines

D · Why it works and complexityO(1) timeO(1) spaceOpen the invariant and proofExplore the proof

ComplexityO(1) time, O(1) space — A couple of comparisons and a string build — constant work, constant space, independent of the year.

E · Edge cases and pitfalls6year = 1900 — Julian (≤ 1917): 1900 % 4 == 0 → leap → 12.09.1900. Under Gregorian it would be common — the era matters.Explore edge cases

Edge cases handled

year = 1900Julian (≤ 1917): 1900 % 4 == 0 → leap → 12.09.1900. Under Gregorian it would be common — the era matters.
year = 2000Gregorian: 2000 % 400 == 0 → leap → 12.09.2000. The 400-exception keeps it a leap year.
year = 1917Last Julian year: 1917 % 4 != 0 → common → 13.09.1917.

Pitfalls

Forgetting 1918 entirely and printing 13.09.1918 instead of 26.09.1918.
Applying Gregorian century rules to years ≤ 1917 (e.g. wrongly calling 1900 common).
Dropping the zero-pad and printing 13.9.2017 instead of 13.09.2017.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Editable code previewpublic String dayOfProgrammer(int year) { if (year == 1918) { return "26.09.1918"; // transition year } boolean leap;Explore the playground

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Wrong leap rule for the era

Before 1918 the calendar is Julian: every multiple of 4 is a leap year. Applying Gregorian century exceptions wrongly marks 1700, 1800, 1900 as common.

Explore the code comparison

Don't write this

boolean leap = year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);  // wrong for year <= 1917

Write this instead

boolean leap = (year < 1918)
    ? year % 4 == 0
    : year % 400 == 0 || (year % 4 == 0 && year % 100 != 0);

Missing the 1918 transition

1918 deleted 13 days from February, so the 256th day is 26.09, not the usual 13.09. Folding it into leap logic silently gets it wrong.

Explore the code comparison

Don't write this

leap = year % 400 == 0 or (year % 4 == 0 and year % 100 != 0)
return f"{'12' if leap else '13'}.09.{year}"   # gives 13.09.1918

Write this instead

if year == 1918:
    return "26.09.1918"
# ... normal leap logic for every other year

Unpadded date format

The required format is dd.mm.yyyy. September must print as 09 and the day as two digits; 13.9.2017 fails the checker.

Explore the code comparison

Don't write this

return f"{day}.{9}.{year}"        # 13.9.2017

Write this instead

return f"{day:02d}.09.{year}"     # 13.09.2017

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Branch on the calendar, then closed-form the date

Code pattern to memorize

if year == 1918: return "26.09.1918"
if year < 1918:  leap = (year % 4 == 0)                  # Julian
else:            leap = (year % 400 == 0) or (year % 4 == 0 and year % 100 != 0)  # Gregorian
return ("12" if leap else "13") + ".09." + str(year)

Rules to remember

11918 is the transition year and the trap: switching from Julian to Gregorian deleted 13 days that February, so the 256th day is 26.09.1918. Hardcode it.
2Years ≤ 1917 use the Julian rule — leap iff year % 4 == 0. The % 100 and % 400 exceptions do not exist yet.
3Years ≥ 1919 use the Gregorian rule — leap iff divisible by 400, or divisible by 4 but not by 100.
4The 256th day is always in September for normal years: Jan–Aug is 243 days common / 244 leap, so day 256 is the 13th or 12th of September.
5Output is fixed-width dd.mm.yyyy — zero-pad day and month (26.09.1918), never 26.9.1918.

Use this pattern when

Date / calendar arithmetic with calendar-system changes
A fixed day-of-year mapped to a concrete date
Leap-year reasoning where the rule depends on the era
A small set of regimes you can branch over in O(1)

Choose another pattern when

Arbitrary date differences across many years → use a date library or epoch days
Time zones / hours / minutes involved → far beyond integer day counting
You must handle every historical calendar quirk → this problem only spans one transition
The day-of-year is an input that varies → loop over months instead of hardcoding September

Interview takeaway

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Same pattern

←

Sum of Digits (Digital Root)

Continue · Next problem

Drawing Book