diff options
Diffstat (limited to 'NEXT_LEVEL.md')
| -rw-r--r-- | NEXT_LEVEL.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/NEXT_LEVEL.md b/NEXT_LEVEL.md index 91f8151..5dd9e1b 100644 --- a/NEXT_LEVEL.md +++ b/NEXT_LEVEL.md @@ -16,7 +16,7 @@ * VJOURNAL entries on a calendar is meant exactly for meeting notes ... probably as well as recording things like who was really participating in an event, and how much time did they spend on it? -* Tasks have a DTSTART and either a DUE or a DURATION; the latter two are interchangable, the standard defines that the DURATION is the difference between DTSTART and DUE. The standard is a bit unclear on exactly what those timestamps are to be used for. I assume the DUE is the "hard" due date where a task should be completed. It makes sense to let DURATION be the time estimate for the task, then DTSTART will be the latest possible start time if the task is to be completed before the DUE date. In my opinion DTSTART is the natural attribute to be used either for the actual expected starting time for working with the task, but I've rather been using it for something like "the time when I should start considering thinking about when the task should be done". +* Tasks have a DTSTART and either a DUE or a DURATION; the latter two are interchangable, the standard defines that the DURATION is the difference between DTSTART and DUE. The standard is a bit unclear on exactly what those timestamps are to be used for. I assume the DUE is the "hard" due date where a task should be completed. It makes sense to let DURATION be the time estimate for the task, then DTSTART will be the latest possible start time if the task is to be completed before the DUE date. This breaks with my usage up until now; I've used DTSTART as when I'm planning to consider to start working on the task. * Calendar components can be linked through the RELATED-TO-attribute. Valid relationship types are "CHILD", "PARENT" and "SIBLING". I suppose it is intended for direct asynclic graphs, where a calendar component preferably should have only one PARENT, and where there shouldn't be loops (my grandchild cannot possibly also be my grandparent) - and that two SIBLINGs have the same PARENT. |