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.
SimpleTask Cloudless has been my favourite todo.txt app for Android. Unfortunately, SimpleTask is in low maintenance mode [1], and does not work well in my setup.
According to mpcjanssen: "The suspending of the applications by Google #1102 and the continuously fixing breakage by Android API changes have reduced my Simpletask motivation to a very low level." [1].
I'm not sure it's even in maintenance mode at this point. I wish I had the skills to maintain it as I quite like SimpleTask and may, even if unsupported, go back to it. Nothing compares on Android.
pimsync synchronises CalDav to a directory where each event is an icalendar file. You can use khal or any other tool to operate in these files.
This tools is a successor to vdirsyncer, which filled a similar role but with several limitations.
I’ve working in Pimsync for many months now. The basics all work fine, but still working in some extended feature. Feedback is most welcome at this stage.
For reminders and other automated actions,
pydry suggested "orgzly revived with org mode"; and kruffalon suggested 'remind'. I have not tried those, but they might be better options for notifications and reminding than calendar.txt.
I use calendar.txt on a cell phone with Markor text editor. For my desktop, I just use micro editor on terminal, the same I use for most text editing tasks.
Bookkeeping using plain text files sounds both interesting and challenging.
> Bookkeeping using plain text files sounds both interesting and challenging.
It has quite a bit of a following; I personally would never switch back to some more "complete" application. I believe all the most popular implementations are listed here: https://plaintextaccounting.org/
FWIW, I'm a single-person company with a tiny turnover and only a handful of expense categories. I've used ledger-cli for many years, but at one point, I started to migrate my data to pta [1]. The reason was that in my country (Europe), all reporting seems to implicitly rely on a numbered chart of accounts (something like "101 Cash", "201 Accounts payable" etc), and the journal format of ledger-cli is not built around this idea by default.
pta, however, does this numbering [2], so for filing taxes in my country, its journal format seems more straightforward in case auditors should have any interest in it. I also quite like its terseness (1 transaction = often 1 line, as compared to 3 in a ledger-cli journal -- gives a better overview and is somewhat better to parse further with sed or awk when needed [3]). Finally, it is a single Perl script, thus very portable and lightweight.
All that said, pta doesn't seem to have much of a following, as compared to ledger-cli, which, obviously, is a much more mature project.
There was also an interesting discussion regarding pta vs ledger, involving the author, OpenBSD dev Ingo Schwarze [4] -- well worth a read regarding the general plain text accounting philosophy also. Interesting stuff.
Not marttt, but I'm a big fan of beancount after using it for the past few years for my company's books. Recycling an old comment of mine that might be helpful: https://news.ycombinator.com/item?id=37937942 (more upthread from that as well)
I’d be interested to read a blog post about your setup. I’m about to start doing my own bookkeeping for my business, and was planning on doing it all in neovim.
It's conflating a format for recording calendars with a syntax the user needs to write.
That syntax looks quite brittle and not very intuitive. One day = one line would get unwieldy fast. It doesn't localise well and there's no obvious way to implement recurring events beyond daily actions. (From what I can see at least?)
You could build a client on top of that but then, you lose the benefit.
It's a neat idea and it's good to see someone share a simple concept that works for them. But I don't see it working for most people.
> You could build a client on top of that but then, you lose the benefit.
disagree. having the data in a simple format makes it syncable, trackable, and guarantees that even if you don't have access to the software you're used to, you can always edit it by hand as long as you can access the file.
you can build some software on top of it; or better yet, build sync plugins for existing software, and benefit from nicer UX without giving up the benefits.
> Unix philosophy. It's one day, one line. You can grep (only show lines).
Surprisingly, grep is able to output several lines, so even if you were to use a (say) more sensible format of one line per event, grep could still output all lines, and display them.
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've got something very similar as a function in my ~/.zshrc, except instead of days separated by lines I start a new file for each topic.
Most of my notes are write-only for a day or so but I keep the old ones around just in case I need to grep through everything (and I've saved myself doing this a few times).
function notes {
THIS_MONTH="$(date '+%Y-%m')"
mkdir -p "$NOTES_FOLDER/$THIS_MONTH" # create folder if it doesn't exist.
cd "$NOTES_FOLDER/$THIS_MONTH"
if [ -z "$1" ]; then
return 0
fi
vim $1
cd -
}
Running `notes` will take you to today's directory to poke around, and `notes file.md` will open file.md in the appropriate dir.
I do something very similar for my public notes as well! I have `tn` to search for a note and open it in a browser, and `tne foo` to open my `foo.md` note in my editor, which in this case is not vim. I then commit them to git, where a post-commit hook uses mkdocs to build them, and gh-deploy to publish them EG https://danielhoherd.com/tech-notes/exiftool/ is the output of my exiftool.md note.
I use vimwiki[1] just for this "diary" functionality, with different days in different files. Can browse the directory in netrw to find a day's notes, and I have scripts that let me archive old stuff. I tend to put an "x" in front of completed lines (and move uncompleted lines forward to new days) so it is easy to detect and archive unactionable or "completed" files.
For people interested in non-Vim alternatives, Logseq and Org-mode both streamline a very similar workflow. (I’m one of those who eventually migrated from Vim to Emacs because of Org-mode, now combined with Howm-mode.)
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.
This is close to what I want. I manage all my calendars in radical caldav server and want a sharable calendar that just shows the empty spots between all calendars with minimal detail fo easy scheduling.
It would be nice if Radicale could serve a FREEBUSY URL which takes contents from a your calendars. Some applications support this format and can help with scheduling meetings. I never got to use it in practice though.
I'd be way more comfortable with a VPN or some kind of access-gating for a personal calendar compared to just exposing it on the web and relying on obscurity..
Web calendars don't offer authentication. You have to build it into the URL anyway. If a service I use -- let's say my bank's chequing account, wants to offer a calendar I can subscribe to, I'll be given a URL that looks like https://somebank.com/api/cal?token=abc12345. Anyone who knows that URL can see the calendar as well. No different than my own web app where the URL is https://mysite.com/dev/cal_abc12345.ics.
For a personal calendar, I see no reason to make it any more secure than an obscure URL.
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.
* [ ] 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.:
This is a much nicer format than the one in the linked article.
I think my approach would be to generate a file in Markdown, then import that into a good Markdown editor. You could generate it each week or month from a template, making it easier to add repeating tasks like exercise and dog walking.
I think the format I suggested would parse in markdown, but I created it pre-markdown.
For me the best parts are:
1. You could write a parser very quickly.
2. It's very easy to edit and add to as a human.
3. It can easily be tracked in git or via a diff-based tool.
I did already think about the repetitive tasks, a long time ago I used to have a tool that would look at the past tasks and recommend future tasks (with appropriate distributions). One example was booking a dentist appointment every 6 months, even if I forgot to schedule something it would remind me to book one in, dismiss it or push it back.
I use a small paper planner that I keep in my pocket at (nearly) all times. People are taken aback and ask why I don't use something more modern, but why should I? This works better, for me, than anything else I ever tried.
It's unfair to computers how well paper planners worked. Among with todo.txt, paper calendars were an inspiration and a benchmark for writing calendar.txt.
> 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.
Periodically my task system fails (the Taskwarrior 3 disaster being the most recent) and this is pretty much what I end up using. But then I forget a bill or something important because there are no bells or buzzers keeping me as a useful working unit. Then I erect the previous system, or some variant, and go with that until some inevitable breakage sends me back to paper. So it goes...
Nested list of checkboxes in markdown is exactly how I organize my work days - I write it I every morning, and then review it every afternoon before I power down. It’s basically job-journaling, it helps fix everything in my head day-to-day.
This format is terrible for working with line-based tools; you need to go an unknown number of lines back to get the date or the time.
Although, TBH, the OP's suggestion of one-line-per-day puts too many items on the same ling. I would have gone with one line per event. Yes, there's more repetition, but you need no out-of-line context, you have to do a lot less parsing, and you can look at a fixed number of _columns_ and get the beginning of the description of each event, which is nicer for manual searching.
To mark the parsing of the day and to note that any incomplete tasks that I intend to keep have been re-planned to elsewhere. Any marked days are then there for historic purposes only.
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?!
I use a template [1] that has the dates (including week numbers) there already. That way, I only need a text editor.
In my work, similar events happen on the same week numbers in different years. The importance of week numbers probably depends on your area of work.
For me, one thing is a day. That's also the context I need when reviewing and planning. But if I remember correctly, previous HN thread on calendar.txt had a suggestion where someone had an event-per-line format, if you prefer that.
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 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 :).
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.
Exactly. Some people are looking at the format and thinking "well, this doesn't do much" but they're missing the point: it's a plain text format that plays very well with other common tools such that 'doing more' is trivial.
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.
I use syncthing for notes across iOS and macOS devices and I wouldn't say it's great. It works most of the time until it doesn't, until one client all of a sudden stops syncing and then you gotta figure out where it's hanging. Couple of days ago it was the macOS syncthing app. Just wouldn't start, wouldn't show an error. Usually it's the iOS helper app "Möbius Sync" not actually syncing in the background. It's annoying but still better than using a cloud provider.
Note that work on the official android app is discontinued
https://github.com/syncthing/syncthing-android
---
"Discontinued
This app is discontinued. The last release on Github and F-Droid will happen with the December 2024 Syncthing version."
If you find Syncthing too chatty and is a bit suspicious to what it connect to, you can really to set it up to only connect explicitely between nodes in a Tailscale network for example.
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.
Based on the man page, calendar(3) would not suit my use well. It's quite different from calendar.txt. But I'm happy to hear that you use it.
I installed it just to read the man page: """
LANG=C
Easter=Ostern
#include <calendar.usholiday>
#include <calendar.birthday>
6/15\tJune 15 (if ambiguous, will default to month/day).
Jun. 15\tJune 15.
15 June\tJune 15.
Thursday\tEvery Thursday.
June\tEvery June 1st.
15 *\t15th of every month.
May Sun+2\tsecond Sunday in May (Muttertag)
04/SunLast\tlast Sunday in April,
\tsummer time in Europe
Easter\tEaster
Ostern-2\tGood Friday (2 days before Easter)
Paskha\tOrthodox Easter
Very recently, I tried using a combination of nail(1), and calendar(1) on OpenBSD as an email and calendaring combination for home use. "nail" is provided by the OpenBSD s-nail package and provides an extended POSIX mailx style environment. calendar(1) is part of the base OpenBSD distribution.
It worked far better than expected. The only thing missed was age calculations for birthdays. I never figured that out. Using the Emacs Diary provided that sort of thing though.
I've since moved to KDE Kontact for mail/calendaring. It works more smoothly if you do a lot of calendar sharing with others, but I could see going back to nail(1)/calendar(1) if Kontact disappoints.
>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.
I'm an AI curmudgeon in general but this is a place where LLMs really excel. You ask "how do I do x thing I want to do" and it either tells you, from the morass of docs it knows about, or it hallucinates and you find out ten seconds later when there's no man page for the command -- and then you fall back to traditional methods.
Either the LLM gives you a discoverability shortcut, or you're back where you started, anyway.
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.
As you guessed, roland35, I do track my calendar.txt in git.
One main benefit from git is also to work as an insurance against (user) errors, and make the whole process much more transparent. When I have used calendars with automatic synchronization, I would have enjoyed a "change log" to make sure that my timezones and meetings are not mistakenly modified by software.
For your dentist example, I would probably just use 'grep' or find in my text editor. After all, six months of days is very little text.
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.
Interesting ideas for formalization and metadata, jeroendh. Some comments on those:
Calendar.txt is indeed a personal calendar. So feel free to violate the spec as much as you need or want to.
My main use for calendar.txt is editing with text editor, and thus, I have not given emphasis to automatic modification.
Time notation is ISO-8601 date and week number. In my view, ISO-8601 is an international standard and not tied to a specific country. I find it convenient to read and sort.
I use local time for physical events. For international calls, I just write down the timezone "13:00Z" or "11:00EET" (update: or mark it in my local time).
At-sign "@" for context was chosen to match todo.txt, as I also use that. As the calendar is personal, it does not need to be fully machine readble. But for your example on email addresses, you could still do it: @WORK email bob@example.com. The context starts with an at "@", email does not.
Full stop "." is easy to type on a cell phone. It's true that a rare char would be more suitable for automatic parsing.
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?
That was my first thought too; I often use Google Sheets/Excel as a lightweight todo calendar, and I'll make formulas to calculate week-of-year and day-of-week. These lists are so lightweight and adhoc that having to do that kind of calculation would be enough friction to not maintain the lists after a short period
With some traditional GUI calendar software, I was often hunting and miscopying week numbers. Some software also had a weird (non ISO-8601) idea of week numbers.
In case you need calendar.txt after 2033, I wrote a small tool [2] to generate more templates.
Static binaries generated by Go are indeed large, even if the source code here is under 30 lines with support to some additional minor features (US and Finnish day names, command line help, optional week headings, day counts and parameter handling).
Here are some more scripts to generate calendar.txt date format:
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.
> one line per event, so good luck finding multi-day events like “Grandma is visiting”
The format allows for variable granularity and ranges. If Grandma were visiting for a week, it would be fine:
2021-02-20 w07
Right now, the range (start-end) can only be hours, but changing that could fulfil your requirement, e.g.
2012-02-20 w07 Mon-Fri Grandma is visiting
> grepping is really not how most people interact with a calendar.
I don't think the creator ever suggested for one minute that this is a calendar for "most people"! Most people don't use Linux, macOS, or a command line.
> sorting by date must be done manually, my god.
| sort
is not much of a hardship. At least it's possible, unlike a typical GUI app that doesn't support sort.
You're quite right, oneeyedpigeon. The main audience of calendar.txt are people who always have terminal open, and who are using grep, sort and similar all the time anyway.
I use +plustags for multiday and recurring events. So for each line +grandma is visiting, I would add the tag +grandma.
I take similar approach with my courses, +tt for pentesting (from the word in Finnish). I found that for me, creating and validating recurring and multiday events was easier for me. Of course, your mileage may vary.
Smikhanov, you found copy pasting challenging. For me, copy pasting from some dedicated calendar software was a challenge. Copy-pasting with calendar .txt makes it easier for me to keep date, week number, weekday and the event together. And your comment on paper planners was on the spot, I wanted to catch some of their benefits, transparency and reliability with calendar.txt.
I believe software is a form of literacy, not engineering. And I believe everyone should be literate it brings great benefits socially and individually
And if this works for him/her it’s a calendar on a piece of paper stuck to the fridge. Great, it works for them and some people might find it good for them too
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.
I love having the system-of-record being something powerful on a laptop, alongside having some paper artifact with just a small constrained view, which you update with a pencil and then reconcile with the SoR later.
This is what I do for todos and reminders, with a few index cards binder-clipped together with a tiny pen. I use [0]; its size is right but it’s just a ballpoint refill that isn’t particularly great. Using it makes me miss my typical fine-tip gel pens. Anybody else use this kind of system and have a tiny pen to recommend?
ill tell you a funny, in January I gave my old boss (who passionately hates technology) my text file and told him he only forgot to pay two days in the (hectic) year. (I make one txt per year) It listed what work was done and with who.
His response was WOAH, I've always wanted this! He then send the whole thing to the printer and put it on the wall in his office. Then he added arrows to the days he forgot to pay using a ballpoint pen. He talked a bit about periods in the year and used his finger as a pointing device.
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.
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.
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.
I always thought the same for todo.txt. Feels like showing a set of columns depending on the task and level of detail needed would be ideal. Someday I hope to tape together a proper todo.csv and calendar.csv ecosystem.
I'm pretty sure the entire world uses ical files. It's a bit of an annoying format to parse, though. The calendar.txt file format seems to be made for people to interact with it directly through a terminal (which the target audience probably already had open).
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.
This is definitely in the camp of oversimplifying by missing the whole problem domain.
We need to come up with a name for that, considering how often it happens.
Hmm, there should be an xkcd for this... [0]
[0]: https://xkcd.com/927/
I’ve used this tool before for caldav: https://github.com/pimutils/khal
khal supports caldav: https://github.com/pimutils/vdirsyncer
There is a task equivalent, which also supports caldav sync
https://github.com/pimutils/todoman
todo.txt accomplished this with community apps that provided web and mobile interfaces to the text file: http://todotxt.org/
The problem is that most those tools end up unmaintained.
Yeah, simpletask
SimpleTask Cloudless has been my favourite todo.txt app for Android. Unfortunately, SimpleTask is in low maintenance mode [1], and does not work well in my setup.
According to mpcjanssen: "The suspending of the applications by Google #1102 and the continuously fixing breakage by Android API changes have reduced my Simpletask motivation to a very low level." [1].
[1] https://github.com/mpcjanssen/simpletask-android/issues/1110
I'm not sure it's even in maintenance mode at this point. I wish I had the skills to maintain it as I quite like SimpleTask and may, even if unsupported, go back to it. Nothing compares on Android.
pimsync synchronises CalDav to a directory where each event is an icalendar file. You can use khal or any other tool to operate in these files.
This tools is a successor to vdirsyncer, which filled a similar role but with several limitations.
I’ve working in Pimsync for many months now. The basics all work fine, but still working in some extended feature. Feedback is most welcome at this stage.
https://pimsync.whynothugo.nl/
For reminders and other automated actions, pydry suggested "orgzly revived with org mode"; and kruffalon suggested 'remind'. I have not tried those, but they might be better options for notifications and reminding than calendar.txt.
I use calendar.txt on a cell phone with Markor text editor. For my desktop, I just use micro editor on terminal, the same I use for most text editing tasks.
Bookkeeping using plain text files sounds both interesting and challenging.
> Bookkeeping using plain text files sounds both interesting and challenging.
It has quite a bit of a following; I personally would never switch back to some more "complete" application. I believe all the most popular implementations are listed here: https://plaintextaccounting.org/
So many tempting options...
Can you recommend a tool and open your accounting workflow, marttt?
Are there any pain points, like filling tax forms or handling travel paperwork?
FWIW, I'm a single-person company with a tiny turnover and only a handful of expense categories. I've used ledger-cli for many years, but at one point, I started to migrate my data to pta [1]. The reason was that in my country (Europe), all reporting seems to implicitly rely on a numbered chart of accounts (something like "101 Cash", "201 Accounts payable" etc), and the journal format of ledger-cli is not built around this idea by default.
pta, however, does this numbering [2], so for filing taxes in my country, its journal format seems more straightforward in case auditors should have any interest in it. I also quite like its terseness (1 transaction = often 1 line, as compared to 3 in a ledger-cli journal -- gives a better overview and is somewhat better to parse further with sed or awk when needed [3]). Finally, it is a single Perl script, thus very portable and lightweight.
All that said, pta doesn't seem to have much of a following, as compared to ledger-cli, which, obviously, is a much more mature project.
There was also an interesting discussion regarding pta vs ledger, involving the author, OpenBSD dev Ingo Schwarze [4] -- well worth a read regarding the general plain text accounting philosophy also. Interesting stuff.
1: https://mandoc.bsd.lv/pta/
2: https://cvsweb.bsd.lv/pta/accounts.example.en?rev=1.3&conten...
3: https://cvsweb.bsd.lv/~checkout~/pta/journal.example.en?rev=...
4: https://www.undeadly.org/cgi?action=article;sid=202009281234...
Those pta example files you linked, marttt, really make the case for this software. It looks simple, transparent, auditable, versionable and unixy.
Dpifke, beancounter looks nice, big and well tought out. I bookmarked the docs/ to have a more troughout look at it later.
Update: Had a more detailed look on Beancount.
LWN's editor Jonathan Corbett has looked into this matter much over the years with numerous articles on the topic.
The end-of-search post is here, with the final choice being GnuCash:
<https://lwn.net/Articles/925782/>
HN discussion (200+ comments): <https://news.ycombinator.com/item?id=36021197>
You'll find at least some of the other posts in the series, and related articles, here:
<https://duckduckgo.com/?q=site%3Alwn.net+accounting+software...>
Not marttt, but I'm a big fan of beancount after using it for the past few years for my company's books. Recycling an old comment of mine that might be helpful: https://news.ycombinator.com/item?id=37937942 (more upthread from that as well)
I’d be interested to read a blog post about your setup. I’m about to start doing my own bookkeeping for my business, and was planning on doing it all in neovim.
> 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.
Without any explanation, this comment isn't particularly productive. Can you explain how it doesn't do it well?
I am also sceptical.
It's conflating a format for recording calendars with a syntax the user needs to write.
That syntax looks quite brittle and not very intuitive. One day = one line would get unwieldy fast. It doesn't localise well and there's no obvious way to implement recurring events beyond daily actions. (From what I can see at least?)
You could build a client on top of that but then, you lose the benefit.
It's a neat idea and it's good to see someone share a simple concept that works for them. But I don't see it working for most people.
> You could build a client on top of that but then, you lose the benefit.
disagree. having the data in a simple format makes it syncable, trackable, and guarantees that even if you don't have access to the software you're used to, you can always edit it by hand as long as you can access the file.
you can build some software on top of it; or better yet, build sync plugins for existing software, and benefit from nicer UX without giving up the benefits.
I would say it doesn't do anything. It may has well defined what should be done - but doing it well and correctly is burdened upon the user.
It even says:
> Unix philosophy. It's one day, one line. You can grep (only show lines).
Surprisingly, grep is able to output several lines, so even if you were to use a (say) more sensible format of one line per event, grep could still output all lines, and display them.
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:
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:
I've got something very similar as a function in my ~/.zshrc, except instead of days separated by lines I start a new file for each topic.
Most of my notes are write-only for a day or so but I keep the old ones around just in case I need to grep through everything (and I've saved myself doing this a few times).
Running `notes` will take you to today's directory to poke around, and `notes file.md` will open file.md in the appropriate dir.I do something very similar for my public notes as well! I have `tn` to search for a note and open it in a browser, and `tne foo` to open my `foo.md` note in my editor, which in this case is not vim. I then commit them to git, where a post-commit hook uses mkdocs to build them, and gh-deploy to publish them EG https://danielhoherd.com/tech-notes/exiftool/ is the output of my exiftool.md note.
I use vimwiki[1] just for this "diary" functionality, with different days in different files. Can browse the directory in netrw to find a day's notes, and I have scripts that let me archive old stuff. I tend to put an "x" in front of completed lines (and move uncompleted lines forward to new days) so it is easy to detect and archive unactionable or "completed" files.
[1]: https://github.com/vimwiki/vimwiki
For people interested in non-Vim alternatives, Logseq and Org-mode both streamline a very similar workflow. (I’m one of those who eventually migrated from Vim to Emacs because of Org-mode, now combined with Howm-mode.)
I made a small utility to make this easier:
https://pypi.org/project/dia/
The problem of "grep but with indents" by making a shell function/script that just invokes the appropriate arcane sed commands.
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.
This is close to what I want. I manage all my calendars in radical caldav server and want a sharable calendar that just shows the empty spots between all calendars with minimal detail fo easy scheduling.
It would be nice if Radicale could serve a FREEBUSY URL which takes contents from a your calendars. Some applications support this format and can help with scheduling meetings. I never got to use it in practice though.
Would love to see the code for this! Do you have it available?
Could you elaborate on the "hidden URL"?
Just a hard to guess one. Like using UUID or things.
I'd be way more comfortable with a VPN or some kind of access-gating for a personal calendar compared to just exposing it on the web and relying on obscurity..
Web calendars don't offer authentication. You have to build it into the URL anyway. If a service I use -- let's say my bank's chequing account, wants to offer a calendar I can subscribe to, I'll be given a URL that looks like https://somebank.com/api/cal?token=abc12345. Anyone who knows that URL can see the calendar as well. No different than my own web app where the URL is https://mysite.com/dev/cal_abc12345.ics.
For a personal calendar, I see no reason to make it any more secure than an obscure URL.
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 )
I especially like your 'mgrep', please do write it!
I have considered similar tools that make use of MarkDown syntax, I feel that there are many tools waiting to be written here.
I think mdq [1], which was recently on HN somewhere, fits this.
[1] https://github.com/yshavit/mdq
Mdq seems just what I've been looking for. I have yet to test it.
Based on documentation, you can mdq for the chapter whose heading is "## Foobar"; or extract all lists in chapter "### Xyzzy".
Thanks, abound!
Update: mdq discussion https://news.ycombinator.com/item?id=43152704
My format used to be as follows:
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.:
This is a much nicer format than the one in the linked article.
I think my approach would be to generate a file in Markdown, then import that into a good Markdown editor. You could generate it each week or month from a template, making it easier to add repeating tasks like exercise and dog walking.
I think the format I suggested would parse in markdown, but I created it pre-markdown.
For me the best parts are:
1. You could write a parser very quickly.
2. It's very easy to edit and add to as a human.
3. It can easily be tracked in git or via a diff-based tool.
I did already think about the repetitive tasks, a long time ago I used to have a tool that would look at the past tasks and recommend future tasks (with appropriate distributions). One example was booking a dentist appointment every 6 months, even if I forgot to schedule something it would remind me to book one in, dismiss it or push it back.
I use a small paper planner that I keep in my pocket at (nearly) all times. People are taken aback and ask why I don't use something more modern, but why should I? This works better, for me, than anything else I ever tried.
It's unfair to computers how well paper planners worked. Among with todo.txt, paper calendars were an inspiration and a benchmark for writing calendar.txt.
> 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.
Periodically my task system fails (the Taskwarrior 3 disaster being the most recent) and this is pretty much what I end up using. But then I forget a bill or something important because there are no bells or buzzers keeping me as a useful working unit. Then I erect the previous system, or some variant, and go with that until some inevitable breakage sends me back to paper. So it goes...
Nested list of checkboxes in markdown is exactly how I organize my work days - I write it I every morning, and then review it every afternoon before I power down. It’s basically job-journaling, it helps fix everything in my head day-to-day.
This format is terrible for working with line-based tools; you need to go an unknown number of lines back to get the date or the time.
Although, TBH, the OP's suggestion of one-line-per-day puts too many items on the same ling. I would have gone with one line per event. Yes, there's more repetition, but you need no out-of-line context, you have to do a lot less parsing, and you can look at a fixed number of _columns_ and get the beginning of the description of each event, which is nicer for manual searching.
I think it's somewhat passable with line-based tools, i.e. you could easily use sed to match a range [1].
I think that it's far more important that it is human readable, if it becomes too tricky to edit manually, then just go with a database.
[1] https://unix.stackexchange.com/a/236754
If you like this you might like org-mode
Why did you make the day itself into a checkbox? Did you use this for weekly reviews or something?
To mark the parsing of the day and to note that any incomplete tasks that I intend to keep have been re-planned to elsewhere. Any marked days are then there for historic purposes only.
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?!
I use a template [1] that has the dates (including week numbers) there already. That way, I only need a text editor.
In my work, similar events happen on the same week numbers in different years. The importance of week numbers probably depends on your area of work.
For me, one thing is a day. That's also the context I need when reviewing and planning. But if I remember correctly, previous HN thread on calendar.txt had a suggestion where someone had an event-per-line format, if you prefer that.
[1] https://terokarvinen.com/2021/calendar-txt/calendar-txt-unti...
Emacs got you covered, my friend, no reason to reinvent the wheel:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Fo...
The diary is fine, but have you seen org-mode?
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 your future proof year numbering. Most current date formats are going to have a BIIG problem come the end of 9999 but not you!
https://en.m.wikipedia.org/wiki/Clock_of_the_Long_Now
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
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.
Such an alarm system would be interesting (and even sounds feasible), even though I don't use reminders myself.
Exactly. Some people are looking at the format and thinking "well, this doesn't do much" but they're missing the point: it's a plain text format that plays very well with other common tools such that 'doing more' is trivial.
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.
I use my Gmail drafts as permanent, in-sync notes (with subject as the title of each note) Why?
- No extra app needed
- Keeps them quite hidden / private / secure
- Always easy access (I always have emails open)
- In sync with different devices
> Gmail drafts
> Keeps them quite hidden / private / secure
Not hidden from Google obviously :) At that point, why not just use Keep at that point to get proper support for notes?
ha, well, nothing to hide to that extent.
I don't know about Keep, but it's another app, which is kind of my point - I already use Gmail.
There's also cli access to Keep. And Google keeps on improving integration of mail,calendar,tasks and keep.
cli access to keep --> no its unofficial api gkeepapi would not trust with my gmail credentials
Though limited android keep app has one simple intent using which i create all my notes
I recommend https://syncthing.net/
Works with all file formats, from photos and movies to text files. Cross platform: Linux, Windows, Android, probably also Mac and BSD.
Update: And it's end-to-end encrypted and free, open-source software.
I use syncthing for notes across iOS and macOS devices and I wouldn't say it's great. It works most of the time until it doesn't, until one client all of a sudden stops syncing and then you gotta figure out where it's hanging. Couple of days ago it was the macOS syncthing app. Just wouldn't start, wouldn't show an error. Usually it's the iOS helper app "Möbius Sync" not actually syncing in the background. It's annoying but still better than using a cloud provider.
I suspect the experience is better on Android.
It is much better on Android
Note that work on the official android app is discontinued
https://github.com/syncthing/syncthing-android --- "Discontinued This app is discontinued. The last release on Github and F-Droid will happen with the December 2024 Syncthing version."
If you find Syncthing too chatty and is a bit suspicious to what it connect to, you can really to set it up to only connect explicitely between nodes in a Tailscale network for example.
I just use SyncThing.
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.
Based on the man page, calendar(3) would not suit my use well. It's quite different from calendar.txt. But I'm happy to hear that you use it.
I installed it just to read the man page: """
"""Very recently, I tried using a combination of nail(1), and calendar(1) on OpenBSD as an email and calendaring combination for home use. "nail" is provided by the OpenBSD s-nail package and provides an extended POSIX mailx style environment. calendar(1) is part of the base OpenBSD distribution.
It worked far better than expected. The only thing missed was age calculations for birthdays. I never figured that out. Using the Emacs Diary provided that sort of thing though.
I've since moved to KDE Kontact for mail/calendaring. It works more smoothly if you do a lot of calendar sharing with others, but I could see going back to nail(1)/calendar(1) if Kontact disappoints.
>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.
I'm an AI curmudgeon in general but this is a place where LLMs really excel. You ask "how do I do x thing I want to do" and it either tells you, from the morass of docs it knows about, or it hallucinates and you find out ten seconds later when there's no man page for the command -- and then you fall back to traditional methods.
Either the LLM gives you a discoverability shortcut, or you're back where you started, anyway.
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.
As you guessed, roland35, I do track my calendar.txt in git.
One main benefit from git is also to work as an insurance against (user) errors, and make the whole process much more transparent. When I have used calendars with automatic synchronization, I would have enjoyed a "change log" to make sure that my timezones and meetings are not mistakenly modified by software.
For your dentist example, I would probably just use 'grep' or find in my text editor. After all, six months of days is very little text.
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.
Interesting ideas for formalization and metadata, jeroendh. Some comments on those:
Calendar.txt is indeed a personal calendar. So feel free to violate the spec as much as you need or want to. My main use for calendar.txt is editing with text editor, and thus, I have not given emphasis to automatic modification.
Time notation is ISO-8601 date and week number. In my view, ISO-8601 is an international standard and not tied to a specific country. I find it convenient to read and sort.
I use local time for physical events. For international calls, I just write down the timezone "13:00Z" or "11:00EET" (update: or mark it in my local time).
At-sign "@" for context was chosen to match todo.txt, as I also use that. As the calendar is personal, it does not need to be fully machine readble. But for your example on email addresses, you could still do it: @WORK email bob@example.com. The context starts with an at "@", email does not.
Full stop "." is easy to type on a cell phone. It's true that a rare char would be more suitable for automatic parsing.
Thanks for the ideas!
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?
That was my first thought too; I often use Google Sheets/Excel as a lightweight todo calendar, and I'll make formulas to calculate week-of-year and day-of-week. These lists are so lightweight and adhoc that having to do that kind of calculation would be enough friction to not maintain the lists after a short period
I use a template [1] that includes week numbers.
With some traditional GUI calendar software, I was often hunting and miscopying week numbers. Some software also had a weird (non ISO-8601) idea of week numbers.
In case you need calendar.txt after 2033, I wrote a small tool [2] to generate more templates.
[1] https://terokarvinen.com/2021/calendar-txt/calendar-txt-unti...
[2] https://terokarvinen.com/2021/calendar-txt/calendartxt-gener...
I also wrote a small tool to generate more templates, and it fits in a comment:
seriously, what's a compressed 1.2MB small tool?Nice!
Static binaries generated by Go are indeed large, even if the source code here is under 30 lines with support to some additional minor features (US and Finnish day names, command line help, optional week headings, day counts and parameter handling).
Here are some more scripts to generate calendar.txt date format:
https://terokarvinen.com/2024/format-date-calendar-txt/
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".
Or press <F5>
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.
> one line per event, so good luck finding multi-day events like “Grandma is visiting”
The format allows for variable granularity and ranges. If Grandma were visiting for a week, it would be fine:
Right now, the range (start-end) can only be hours, but changing that could fulfil your requirement, e.g. > grepping is really not how most people interact with a calendar.I don't think the creator ever suggested for one minute that this is a calendar for "most people"! Most people don't use Linux, macOS, or a command line.
> sorting by date must be done manually, my god.
is not much of a hardship. At least it's possible, unlike a typical GUI app that doesn't support sort.You're quite right, oneeyedpigeon. The main audience of calendar.txt are people who always have terminal open, and who are using grep, sort and similar all the time anyway.
I use +plustags for multiday and recurring events. So for each line +grandma is visiting, I would add the tag +grandma.
I take similar approach with my courses, +tt for pentesting (from the word in Finnish). I found that for me, creating and validating recurring and multiday events was easier for me. Of course, your mileage may vary.
Smikhanov, you found copy pasting challenging. For me, copy pasting from some dedicated calendar software was a challenge. Copy-pasting with calendar .txt makes it easier for me to keep date, week number, weekday and the event together. And your comment on paper planners was on the spot, I wanted to catch some of their benefits, transparency and reliability with calendar.txt.
The format is probably ok for non-edit logging like journalling or recording something like weight loss.
Oh I agree … but
I believe software is a form of literacy, not engineering. And I believe everyone should be literate it brings great benefits socially and individually
And if this works for him/her it’s a calendar on a piece of paper stuck to the fridge. Great, it works for them and some people might find it good for them too
But yeah.
“One day I will get organisssseed”
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.
I love having the system-of-record being something powerful on a laptop, alongside having some paper artifact with just a small constrained view, which you update with a pencil and then reconcile with the SoR later.
This is what I do for todos and reminders, with a few index cards binder-clipped together with a tiny pen. I use [0]; its size is right but it’s just a ballpoint refill that isn’t particularly great. Using it makes me miss my typical fine-tip gel pens. Anybody else use this kind of system and have a tiny pen to recommend?
[0] https://www.amazon.com/dp/B0776LK634
The Pilot Petit works well and has been reliable.
A very similar idea and philosophy - http://todotxt.org
I can recommend todo.txt, as I've been using it for years. Todo.txt was one of the inspirations to create calendar.txt.
It also works nicely together with calendar.txt for me. I can 'grep' trough both to see all todos and events related to a project or a +tag.
ill tell you a funny, in January I gave my old boss (who passionately hates technology) my text file and told him he only forgot to pay two days in the (hectic) year. (I make one txt per year) It listed what work was done and with who.
His response was WOAH, I've always wanted this! He then send the whole thing to the printer and put it on the wall in his office. Then he added arrows to the days he forgot to pay using a ballpoint pen. He talked a bit about periods in the year and used his finger as a pointing device.
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.
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
In the spirit of friendly competition; I gotta argue that Skroll's "Remind" supercedes this in every way. More flexible and more powerful.
Absolutely agree. Remind has been around for literally decades and so has tons of user discussions that are easily searchable.
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.
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...
Now my homepage should answer in under 300 ms again. Thanks for visiting!
One event per line might just be better.
`YY-MM-DD:HH:MMa (Optional repeat cron definition) "Event string"`
This is an idea so basic, yet so good, that it should be general knowledge already.
I will try to include it in my custom OS from scratch. Should be simple, right?
Fix the bug where it starts in 2021
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 seems like it'd be much more practical as a CSV file.
I always thought the same for todo.txt. Feels like showing a set of columns depending on the task and level of detail needed would be ideal. Someday I hope to tape together a proper todo.csv and calendar.csv ecosystem.
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.
Programming languages are substantially more complex than text or lists but are edited as text.
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?
Yes [1]. In the unlikely event you need a calendar after 2038-01-19 w03 Tue, the program can generate you templates [2] for hundreds of years [3].
[1] https://terokarvinen.com/2021/calendar-txt/calendartxt-gener...
[2] https://terokarvinen.com/2024/format-date-calendar-txt/dateg...
[2] https://terokarvinen.com/2024/format-date-calendar-txt/
Update: Added the template until 2400.
Is support for 2034 announced?
its https://xkcd.com/927/ all over again
Are there that many calendar formats? I thought iCal was by far the most ubiquitous. I've heard of jCal as well but never seen it in the wild.
I'm pretty sure the entire world uses ical files. It's a bit of an annoying format to parse, though. The calendar.txt file format seems to be made for people to interact with it directly through a terminal (which the target audience probably already had open).
[dead]
[flagged]