From: Nicolas Goaziou <email@example.com>
To: Heiko Schmidt <Heiko.Schmidt@webbedtables.de>
Subject: Re: negative values for EFFORT result in error when switching to column view
Date: Mon, 06 Apr 2020 18:13:34 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Heiko Schmidt's message of "Mon, 6 Apr 2020 17:03:07 +0200")
Heiko Schmidt <Heiko.Schmidt@webbedtables.de> writes:
> This is exactly the reason why I'd love to have negative values for
> the durations. It would open the possibility of doing something like
> "accounting" of time.
I think you can do accounting of time without introducing negative
duration. Basic accounting implies having two categories. You expect
them to be "positive" and "negative", but it could also be "positive in
property A" and "positive in property B".
> I'm working with self defined duration units and it would be of great
> value to be able to calculate the balance for planned and done work
> time. I don't use clocking.
> What'd be wrong about having -0:30 h, -30 min, -2.5 h, -3 d or -3 m?
> It'd be an addition no change so there would hoefully be no
> Maybe even 3m -3d be or -3m 3d could be of use.
No incompatibility doesn't mean no cost. It adds code complexity. You
also have to maintain the feature later on, make sure it doesn't break
future code, etc.
Moreover, I'm not convinced about the general need for such a feature.
Of course, it is possible that I may be missing the point. Org folks may
want to chime in and correct me if I do.
> As I see there is org-duration.el - Have the changes to be made only
I think so. But I suggest to check if you cannot do otherwise (again,
I'm sure you can).
next prev parent reply other threads:[~2020-04-06 16:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 5:09 negative values for EFFORT result in error when switching to column view Heiko Schmidt
2020-04-06 10:13 ` Nicolas Goaziou
2020-04-06 15:03 ` Heiko Schmidt
2020-04-06 16:13 ` Nicolas Goaziou [this message]
2020-04-08 15:18 ` Heiko Schmidt
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).