As a file format, this is just fine, but I feel like there's some conflation between a file format and software meant to interact with that format.

I use plain text accounting for my business, and it's lovely to be able to enter bookkeeping data with a plain text editor and keep it all under version control, but the next step is using a program such as hledger or beancount to work with that data.

I'd love to work with plain text calendar software, but it would still need to do things such as provide a mechanism to work on my desktop and mobile device. It would need to handle recurring events automatically, and it would need to allow me to invite others to events and ideally to track when they've accepted or rejected my invites.

I'd need to be able to update, cancel or propose to move events in such a way that others would be updated.

I wish I knew of a good command line tool to interact with CalDav or similar servers, or that I could maintain my calendar in a file format and then handle the synchronization automatically.

Maybe calendar.txt could play a role in that, but on its own, it's not quite enough for me.

> Unix philosophy. It's one day, one line.

The Unix philosophy is often recited as "do one thing, and do it well". This does one thing, but doesn't do it well at all.

I do something similar for daily notes for work. I have a shell alias `tdw` for `TODO work` which opens a YYYY-MM.md file in vim. Inside of that markdown file I use a vim macro that generates a date similar to what is shown in calendar.txt, where I take notes about what I am working on and what I have worked on. Here's ane example of what it looks like:

    ## 2025-02-27 W09 Thursday
    
    - Team standup
    - Looking up flights to Venus
    - Meeting with Acme
      - Discuss hydrocoptic marzlevanes
      - TODO: read up on them <http://example.com/docs/hydrocoptic-marzlevanes>
    - (personal) Feed the dragon
    - #5934 Fix glitch in dingle arm reciprocator

I kind of like the calendar.txt idea of prefixing every line with the date, because it makes grepping easier, but at the same time, it doesn't allow for sub-lists and more detailed notes about what was worked on. It hasn't been a big enough problem to deal with though, because of things like `grep -i -B10 encabulator`

The vim macro I use is:

    " Macro To Do Today
    nmap mtdt <esc>O<CR><esc>k"=strftime('## %F W%V %A')<CR>Pa<CR><CR>-

I created a super-simple CalDav-esque web endpoint in my personal website that receives HTTP requests from a command line tool, stores the calendar events, and then returns them as a dynamic ICS file. Then, I use Apple’s Calendar app to subscribe to a “hidden” URL and iCloud automatically distributes the subscription to all my devices.

It sounds super dumb but it works so well.

The main feature is that I can categorize the events (personal, family, work, friends, etc.) and share individual URL’s with other people. Admitedly, I didn’t try solving this problem with Google Calendar, Apple Calendar, or any other calendar service, mostly because I wanted to own my data and also learn a bit more about CalDav itself.

For a few years, I evolved a slightly-modified Todo.txt format for this purpose, to represent both tasks and appointments.

http://todotxt.org/

https://www.neilvandyke.org/todotxt/

In some ways it worked well, but there were a few drawbacks, and eventually I switched to native calendar programs on desktop and mobile.

Drawbacks I personally felt:

* In the text file, recurring tasks didn't show up when I looked into the future, such as to schedule an appointment.

* Calendar invites over email weren't integrated, so I had to enter and update those manually anyway. (Though one advantage over the native calendar programs I use now is that todo.txt doesn't force the appointment headline someone else wrote into my calendar view, and refuse to let me edit it in my local copy.)

* I had to keep editing dates on tasks manually, every day, for my "current day view" of top of the file to work with priorities.

* No visual calendar views with the tools I was using.

* No device sync with the tools I was using (though possible).

* There are only so many ways in which I was willing to be a weirdo at once, and this one didn't make the cut.

I don't discourage anyone from trying todo.txt or calendar.txt. Just a heads-up of some things you might want to find solutions/workarounds for.

I like this, but need more detail in my log and have too many things in a given day to have them all on a line. Had the following idea, and will try it out at some point. Call it calendar.md

Use calendar.txt format and method with the following changes:

1) Use markdown, with a top level heading of Calendar (so inclusion is easier) and the portion

2) Use :tag: instead of +tag. Tags can be run together (:tag:tag2:). This helps with Org mode compatibility

3) Third level heading for each event in day, following same format as calendar.txt

4) text under heading is for notes about the event

5) Searching and seeing info on event in day, or summary about day is no longer easy with grep. This is the biggest drawback from not using calendar.txt. Overcome by writing a tool mgrep that is specifically designed to search markdown files in a Markdown aware way (search headings or specific level of headings, show all headings under matching heading or just one level under, show all content under matching headings, search text and show either lines or section text is in optionally along with ancestry of headings).

6) Create CalendarMDMode, minor mode designed to facilitate calendar.md use and editing within Emacs, requires OrgMode, things like shortcuts for new date, new event, in-editor use of mgrep, etc.

7) Attempt to add CalendarMD support to Helix, which is my daily notes editor, using the as-yet unlanded Scheme based plugin system (see https://github.com/helix-editor/helix/pull/8675 )

My format used to be as follows:

    * [ ] YYYY-MM-DD
      * [ ] 1800: Dinner with parents
      * [x] Walk the dog
    * [ ] YYYY-MM-DD
      * [ ] 0900: Interview new recruit
        * [ ] Prepare interview questions
        * [ ] Upload result to HR system

This worked really well for me and was easily searchable. One benefit would be that it is easily trackable in Git.

These days I have a little A6 lined notebook and manually list tasks there. Each page is a new day and the tasks are listed similarly. The only modification is that sometimes I put some letters to theme a task, i.e.:

    * [ ] YYYY-MM-DD
      * [x] Home: Walk the dog

I don't like that week numbers are (documented as) mandatory. I wouldn't see myself grepping on a week number. I'd end up constantly looking up the correct week number in order to annotate each event properly, with no benefit in return. Then again, could write a macro/plugin thingy for one's editor of choice, to fill in the week number for you (ditto for day of week, which I would at least find quite useful, but which would similarly be a right pain to have to fill in manually all the time).

Also: claims to be "one thing per line", yet allows and encourages multiple events on one line (as long as they're on the same day). This is a calendar - is an event not the main "thing" we're dealing with?!

Emacs got you covered, my friend, no reason to reinvent the wheel:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Fo...

I’m skeptical about convenient plain text is, compared to more structured formats, once we try to encode even more of the conveniences we get out of current calendaring (e.g. time zone shifting, notes of indefinite length, events that last the whole day, repeated events…)

There are a few more structured formats for calendaring that share the virtues of their workflows: if we used JSON, would jq be a UNIXy tool? What about sqllite and commandline queries? Both would be much more easier for my overloaded mind - especially when parsing records - without adding more inherent complexity beyond a sufficiently overloaded raw text calendar.

I've been doing this since 02001, except without the week numbers. I switched from CVS to Git around 02009.

Anyone who knows me will tell you I am not very organized. Possibly this is why.

Android support is definitely substandard, even with Termux.

It's not foolproof. On one occasion I typed in the month wrong, though in the right place in the file. When I noticed that the line was out of order, I moved it to where the date said it should be. Arriving a month late, I discovered that the studio space I'd paid for no longer existed.

I like this. It's a lot like Emacs `diary` system. Though, you can group multiple events under one day heading. I will say that I like how `grep`-able this is. As long as you know the rules, it's pretty easy to parse. You could probably whip up an alarm system in bash and cron/systemd and let it alert you like all those big-box programs do.

I did something like this for years before having to switch to an actual calendar app. A text calendar has a lot of advantages, like easily being able to have a list of the current and next days event displayed each time you open a terminal by putting the right call in your .bashrc :).

My text calendar management script is still available here: https://code.up8.edu/pablo/myutils/-/blob/master/kal

Have you looked into remind[0] while working on this?

There might be value in checking that out.

Personally I haven't used it in years, but the latest release is from this year so it seems active.

---- [0] https://dianne.skoll.ca/projects/remind/

To me the biggest block for using any plain text format for daily stuff is I need a good mobile - laptop sync method that I can easily read / write and manage files on both mobile and laptop, does anyone have any recommendation? The best choice I can think right now is SimpleNote which I've been using for notes for a long time, but is there a way I can actually use .txt file instead of text been stored somewhere in a database.

You make a good argument on why to use a plain text calendar, but not why you shouldn't use the `calendar(3)` format. I think this really speaks to the problem of discoverability that standard Unix tools have. A lot of problems have already been solved by those tools that are included on every BSD, every Mac OS computer, and most Linux distributions, but nobody knows about them, and there isn't really a good way to see what already exists. Sure, you could browse `/usr/bin` to see what's available, and I guess that's the Unix Way, but it's unwieldy.

It would be cool if there were a crash course on this stuff, but even that wouldn't work well, because the first time you use a unixy system, it would be too much information to retain, and subsequent times you're likely to just gloss over all this stuff.

Perhaps the only real solution is asking about what you want to do on messages boards, and hoping some weird old curmudgeon who is familiar with the small program you want to use sees your question.

One thing I really would like in a calendar app is some sort of "change log", and this gets somewhat close to that, assuming you track the file in git.

For example, I recently scheduled a dentist appointment 6 months from now. Unless I scroll through the calendar, or specifically search for it, there is no easy way to find that I added that event.

Seems useful for very basic calendar requirements. I'm not seeing much about timezones or anything at all about DST so I'm guessing this format just ignores those for convenience. Saying "times are local to events" is great for physical events but when you're dealing with an international call, you probably want to specify that.

Using a full stop as a separator seems rather limiting, something less likely to appear in an event description such as a vertical pipe would make more sense. Now you'd need some kind of weird logic to write an event titled "read top 10 news.ycombinator.com articles". Using @ as a special character also means you can't store "email support@localhost.com" as an event title.

And, of course, everything is hard coded in English, using English style time notation.

This seems like a fine solution for a personal file format but everyone will probably have to modify it to fit their own needs. If I were to use it, I'd violate the "spec" all over the place by time and date notation alone. This could be fixed by adding some kind of header, but I doubt any full application will ever support a format like this so it's hardly a problem.

If I were to use this as a file format, I'd add headers to store things like language, default time zone, ltr vs rtl, and alter the separator characters. Adding something like a title, an author, and the moment of last edit might also be useful.

I'd personally also probably store events as separate, duplicate lines. That way, you can easily add an event to the bottom of the file without having to find/replace an existing date (or generate an entirely new line). Using basic POSIX tools you can easily get the events back to a single line without making scripts too difficult to read. Assuming culture and other headers match, you'd be able to import another calendar file by simply appending the event lines.

Nice idea, but the calendar format is a bit verbose for my taste. Week number is something I would have to look up constantly and surely get wrong more than once.

If you want to follow UNIX philosophy, why don't you write an augmenter/converter tool `caug` that adds "computed" information such as week number, weekday or even relative date?

  > cat calendar-src.txt

    2025
    ====
    03-01 9-12 project groups

  > cat calendar-src.txt | caug
    2025-03-01 w09 09:00-12:00 project groups +tomorrow 
    +thisweek

  > cat calendar-src.txt | caug | grep "thisweek"
    2025-03-01 w09 09:00-12:00 project groups +tomorrow 
    +thisweek

Tangentially related, but the built-in Windows Notepad still to this day will append the current time and date to a file on opening, if the first line is ".LOG".

Sorry to be a Luddite, but isn’t this completely useless?

- one line per event, so good luck finding multi-day events like “Grandma is visiting”;

- rigid metadata (dates, week numbers, weekdays) stored right next to the editable data (events), so copy-pasting errors are inevitable;

- the most important feature of the real calendar software (reminders) is thrown out;

- grepping is really not how most people interact with a calendar.

If you’re ready to ditch reminders, attachments, locations, use the paper diary planner. At least it won’t let you screw the dates with botched copy-paste.

Update: also, sorting by date must be done manually, my god.

my dad keeps his calendar in an excel file with almost the exact same format except he omits dates with no entries. Every week he prints a new version of this on a single A4 which he folds and keeps in his wallet. new events are hand written at the bottom and get included in the excel weekly. he's been doing this for as long as I can remember.

A very similar idea and philosophy - http://todotxt.org

Previously:

3 days ago, 7 points, 0 comments https://news.ycombinator.com/item?id=43169019

1004 days ago, 202 points, 93 comments https://news.ycombinator.com/item?id=31574125

The first online store/cart I wrote (in php 3 or 4, around 2001), I didn't know sql so I worked backwards into inventing a database from scratch using text files. This was great for a couple years until someone put an asterisk into the name of a product. Asterisk was my row delimiter. lol.

Little known, but there is already calendar(1) [1] in OpenBSD with much more sane format.

[1]: https://man.openbsd.org/calendar.1

I like text based formats for things. But I find that you need software to help with the maintenance and presentation of such things. Todo.txt and plain text accounting are two examples of this; sure you could edit the plain text but a software system just makes it better to use, especially on mobile.

With that in mind I don't see how this is a replacement for caldav. Sure looking at the plain text of a caldav file is worse, especially one generated by a computer, but at least all expected calendar functionality is included. Though the sprawling RFC is hardly simple to follow or implement.

I love it but I believe I am deeper in that rabbit hole.

I just create files in a folder with the `yyyy-MM-dd-hh:mm` format. I use `XX` for recurring events.

I use `at` for reminders/notifications.

In the spirit of friendly competition; I gotta argue that Skroll's "Remind" supercedes this in every way. More flexible and more powerful.

Cool but how do I share events with my family and coworkers so we are on the same page?

The point of calendars is to align with other people’s lives

orgzly revived with org mode

It's like this, but better. I actually get notifications from my calendar text file. I can set some of them as alarms.

Thank you for bringing up calendar.txt. My homepage is feeling the hug. In the meanwhile:

https://web.archive.org/web/20250216110151/https://terokarvi...

One event per line might just be better.

`YY-MM-DD:HH:MMa (Optional repeat cron definition) "Event string"`

Seriously, with the number of invites, slots, to juggle. Might be better to work again like a dev and with text files in an IDE. Would be funny to send invites with raising a PR. Merging, reviewing, ... what a beautiful mess.

This is an idea so basic, yet so good, that it should be general knowledge already.

This seems like it'd be much more practical as a CSV file.

Plain text is fine as a backing format...but not as an interface for something more complicated than text or lists.

Editing this on mobile sounds very annoying.

A nice idea. But imagine you are a manger with a bunch of dates. This will not be very readable

Is support for 2034 on the calendar?

Is support for 2034 announced?

its https://xkcd.com/927/ all over again

[dead]

[flagged]