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.
Calendar.txt
31–40 of 143 posts
Re: Calendar.txt
#32Seriously, 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.
Re: Calendar.txt
#33its 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.
Re: Calendar.txt
#34I 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.
Re: Calendar.txt
#35My 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…
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.
Re: Calendar.txt
#36Seems 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.
Re: Calendar.txt
#37its 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).
Re: Calendar.txt
#38Seems 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 i…
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!
Re: Calendar.txt
#39One 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.
Re: Calendar.txt
#40> 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.
[deleted]