Taiwan calendar converter without upload: how the conversion runs locally

Not because a calendar date is secret, but because the technical claim should stand up to a direct look - here is exactly what runs, and where.

What actually computes the three dates

The ROC (Minguo) year is a fixed, exact offset: ROC year equals the Gregorian year minus 1911. That is plain arithmetic, computed synchronously in the same JavaScript thread that renders the page, on every keystroke.

The lunar calendar cannot be reduced to a simple formula the same way: real lunisolar calendars have leap months and month lengths determined by the actual moon phase and sun position, not by a repeating pattern. For that direction, the tool uses Intl.DateTimeFormat with the "chinese" calendar option - a calculation built into every modern browser as part of its own internationalisation engine (ICU), not something fetched from a server.

Converting the other way, from a lunar date back to a Gregorian one, searches a small local window of dates using that exact same built-in computation, so both directions rely on one shared source rather than two calculations that could ever disagree.

Because none of this needs a lookup table hosted anywhere or a request to a calendar service, there is nothing for a network connection to do in the first place - the absence of any request is not a special feature bolted on, it is simply what a browser-native computation looks like.

How to check this yourself

1. Open your browser's developer tools (F12) and switch to the "Network" panel.
2. Disconnect the internet - airplane mode, or Wi-Fi off.
3. Enter or change a date in any of the three fields (Gregorian, ROC year, or lunar date). All three representations keep updating instantly, and no new entry appears in the Network panel.
4. For a stronger test, reload the page itself while still offline (after having visited it once before) - the page and the conversion both keep working, because nothing about this tool was ever waiting on a server in the first place.

Works offline This tool has no file, no Web Worker and no lazily-loaded component - the whole calculation is plain JavaScript running on the same thread as the page. A genuinely first-ever offline attempt, right after loading the page once, works exactly as well as the hundredth: there is no separate program chunk that needs to be fetched first, unlike the file-processing tools on this site that do use a dedicated Worker.

What this means under GDPR Article 28

Legal background (not legal advice, just context): under GDPR Article 28, a data processing agreement (DPA) is required whenever personal data is handed to a third party for processing - for example when a file is uploaded to a server so that server can convert, read or store it. With gottrix that handover simply does not happen: whatever you enter - a file, or in this tool's case a calendar date - is computed exclusively inside your own browser, so gottrix never sees the value and therefore cannot store, analyse or forward it either. This does not change other obligations that do apply (for the few server requests that genuinely happen - the page load itself, consent-gated analytics); our own privacy policy (/en/datenschutz) covers those. Other providers in this space commonly process input server-side (the value is uploaded, processed there, and deleted after a defined retention period) - that is a technically different, in many cases equally lawful model, but one that requires handing data to a third party and therefore a DPA. This context is not a substitute for individual legal advice.

A single calendar date is rarely personal data in any meaningful sense on its own, so this classification matters less here than it does for a document or an encrypted file - but the underlying technical fact, that nothing you type is ever transmitted, holds regardless of how sensitive any particular date happens to be.

Read the full privacy policy

The difference to a server-side calendar conversion

Some calendar-conversion tools compute the lunar calendar by sending the requested date to a server-side library or an external calendar API and returning the result - a workable design, since the astronomical computation itself is the same either way.

The difference here is simply that the identical computation already exists inside your own browser (as part of its internationalisation engine), so there is nothing to send in the first place: not because the request would be unsafe, but because it is unnecessary.