| 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. |
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!