The file

One .kcal file is one Killendar. It is an ordinary SQLite database, opened and written in place, so you can read it with any SQLite tool without going through the app. There is no proprietary container and no index to rebuild.

Killendars live in %APPDATA%\Killendar, per user, always. A machine-wide install makes the app available to everyone on the box; each Windows account still gets its own Killendar. Nothing is written outside your profile.

What is inside it

• events - one row per appointment.
• categories - the color definitions. They live in the Killendar rather than in settings, so they travel with the file when you move or share it.
• meta - schema version and the app version that created the file, for forensics on a file that turns up years later.

Time

Timed appointments are stored in UTC and converted at the edges, so a calendar carried to another timezone still says the right thing.

All-day entries are the exception, and deliberately so: they are floating calendar dates, stored unconverted with no Z. Converting them to UTC would slide an all-day appointment to the previous day for everyone east of UTC.

Encryption

Encryption is opt-in. With no password the file is plain SQLite. Set one from the lock button in the title bar and the whole file is encrypted at rest with SQLCipher.

The same button changes the password, or removes it and writes the file back out as plain SQLite. An encrypted Killendar asks for its password on launch; a wrong one just asks again.

There is no password recovery

The app says so before you commit to one. If a password is lost the locked Killendar is renamed aside and kept on disk rather than destroyed, and a new empty one opens in its place - so a forgotten password costs you access, not the file.

What the encryption does not protect

Worth stating plainly rather than implying otherwise:

• Nothing is protected while the app is open and unlocked.
• It is no defense against a keylogger, a memory dump, or someone who has your password.
• settings.json stays plaintext. It holds the theme, locale, window position and which Killendar is active.
• An .ics export is plain text by definition. Exporting from an encrypted Killendar writes an unencrypted copy, and the app warns you at the moment of export rather than after.

iCalendar

Import and export are written against RFC 5545 directly, with no external dependencies. Import skips appointments already in the calendar and reports how many were added and how many were skipped.

Categories travel through both, using the standard CATEGORIES property, so they survive a trip through another calendar app. A category you import but have never defined shows in neutral gray rather than being dropped or silently created - deleting a category is meant to stick, and an import should not quietly undo that.

Keyboard

Almost everything is a single key, no modifier. That is only safe because of one rule: a bare-letter shortcut never fires while you are typing. The moment focus is in a text field every single-key binding stands down, so a w in a title is a w and not a jump to week view. The modified combinations are checked first and work regardless, because they cannot collide with typing.

Running it

Only one instance runs at a time. A second launch hands its file to the window already open and exits, rather than leaving two copies of the app writing to one database - which is the quickest way to corrupt SQLite.

Double-clicking a .kcal copies it into your data folder and opens the copy, leaving the original where it is. A Killendar is written to constantly, and SQLite over a network share is a well known way to lose a database.

Signing

Releases are Authenticode signed. The About card shows the publisher, the certificate thumbprint and the SHA-256 of the running exe, and it validates the signature with WinVerifyTrust rather than merely reading the embedded certificate - so a tampered build cannot display a signer it does not own. The chain check is cache-only, so opening About never stalls waiting on the network.

Glossary