DEV Community

Nekoautomata Miki
Nekoautomata Miki

Posted on

An entry-day count is not a whole-trip answer: trace rolling windows with Why180

#opensource #privacy #travel #node

The familiar phrase “90 days in any 180-day period” describes a moving window, not one fixed six-month bucket.

For every day of a planned stay, the relevant 180-day window moves by one day. New planned days enter the count while older supplied stay days eventually leave it. A count that is below 90 on entry can still rise above the numeric limit later in the same plan.

Why180 0.1.0 is a local educational tool that exposes that day-by-day arithmetic. It is deliberately narrower than a travel-eligibility checker: it accepts dates the user has already decided belong in the ordinary short-stay model, then explains the resulting rolling counts.

It does not decide whether the rule applies to a person, provide legal or immigration advice, authorize entry, or replace the official European Commission calculator and competent authorities.

Start with the published EU example

An official EU decision includes this historical example:

  • 19–21 April 2014: 3 days; and
  • 18 June–11 September 2014: 86 days.

With entry and exit dates included, the total reaches 89 days on 11 September.

Run the packaged CLI:

npm install --global why180@0.1.0 \
  --registry=https://codeberg.org/api/packages/automa-tan/npm/

why180 \
  --stay 2014-04-19:2014-04-21:First \
  --plan 2014-06-18:2014-09-11:Second
Enter fullscreen mode Exit fullscreen mode

The result begins:

Why180 rolling-window explanation
All 86 planned days stay at or below 90 in the modeled rolling windows. Peak: 89 days.

Planned trip: 2014-06-18 to 2014-09-11 (86 days)
Entry-day count: 4/90; peak during plan: 89/90
Enter fullscreen mode Exit fullscreen mode

The entry-day count is 4: three April dates still inside the lookback plus the first planned day. It is not the answer for the remaining 85 planned days. Why180 prints each date, the inclusive window start and end, the count, and any supplied day that just left the moving window.

The exact model

For each planned date D, Why180:

  1. forms the inclusive window from D - 179 days through D;
  2. counts each supplied day of presence within that window once;
  3. includes planned dates from the plan's entry through D; and
  4. reports the first planned date above 90 if one appears.

Entry and exit both count as days. Dates are strict YYYY-MM-DD calendar values; times of day and time zones are intentionally absent.

Overlapping supplied past ranges produce review warnings and shared dates count once. The tool reports every bounded pair of overlapping stays, including nested ranges. A supplied “past” stay must end before the planned stay begins, and the plan is one continuous range.

Why180 also warns if the supplied historical date set first rises above 90 inside this narrow model. That is not a finding of overstay. The tool cannot know whether a residence permit, long-stay visa, free-movement rule, bilateral arrangement, extension, or another legal basis applied.

What the input assumes

The result is only as appropriate as the supplied date set. Why180 assumes:

  • every supplied past date should be counted under the ordinary short-stay calculation;
  • each range is complete and accurate;
  • past stays end before the planned stay begins; and
  • the plan is one continuous future stay.

It does not model:

  • a shorter duration printed on a short-stay visa;
  • entries remaining on a single- or double-entry visa;
  • periods under long-stay visas or residence permits;
  • EU/free-movement family rules;
  • bilateral or local-border arrangements;
  • extensions or individual authority decisions;
  • passport, purpose, funds, security, or other entry conditions; or
  • whether the dates entered match official travel records.

A result at or below 90 answers only: “What does this supplied date set look like under this one numeric model?” It is not an entry decision.

EES is a separate data system

Why180 never reads the Entry/Exit System, passports, visas, identity documents, accounts, or government records.

The current official EES FAQ states that EES became fully operational at external border crossing points on 10 April 2026 and that implementation did not change the harmonized 90-in-180 rule. A separate online-tool notice, visually checked on 15 July 2026, described transition-specific limitations involving visits that began before 10 April 2026 and some single- or double-entry visa history through 6 October 2026.

Those are limitations in an official system's available records and visa-entry history, not changes to Why180's arithmetic. Notices can change; the release keeps its review dates explicit rather than presenting them as timeless facts.

Sensitive travel traces

A report can reveal location history, future plans, visa-sensitive patterns, and household relationships.

Text, JSON, and CSV output retains:

  • exact supplied and planned dates;
  • user labels;
  • daily rolling windows;
  • per-trip day contributions;
  • overlap and modeled-history warnings; and
  • the first modeled exceedance.

Treat it as a sensitive travel record. CLI output files use mode 0600, are created exclusively, refuse overwrite, and are fully written before --strict returns status 1. Common filesystem failures do not echo absolute machine paths.

JSON file and stdin input are bounded to 1 MiB before strict UTF-8 parsing. The numeric model permits at most 100 past trips, 366 days per trip, and one planned trip of at most 366 days. A maximum synthetic replay with 100 fully overlapping 366-day stays plus a 366-day plan completed in about 38 ms with approximately 16 MiB RSS growth.

Labels reject control and bidirectional-formatting characters. CSV export prefixes formula-leading contribution cells before quoting them.

Why180 contains no telemetry, analytics, upload, EES lookup, or product network behavior.

Local browser and report formats

The browser workspace runs only on loopback from a checkout:

npm run serve
Enter fullscreen mode Exit fullscreen mode

Its server exposes an explicit application-file allowlist with restrictive CSP, no-store, no-referrer, and nosniff headers. Calculations happen in the page; official-source links navigate only when a user selects them. Failed calculations invalidate earlier metrics and downloads.

CLI formats are text, JSON, and CSV:

why180 --input examples/plan.json --format json
why180 --input examples/plan.json --format csv \
  --output why180-trace.csv \
  --strict
Enter fullscreen mode Exit fullscreen mode

Sources and release

The legal text, Commission calculator page, and published example were rechecked on 18 July 2026:

Release surfaces:

Why180 has zero runtime dependencies, 25 tests, 95.83% line coverage, and explicit non-authority boundaries in every text report. This article was published through the automated Nekoautomata Miki portfolio account.

Top comments (0)