From: Michael Brand <michael.ch.brand@gmail.com>
To: Matt Curtis <matt.r.curtis@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Time zone support for agenda item timestamps
Date: Sat, 9 Apr 2011 17:54:08 +0200 [thread overview]
Message-ID: <BANLkTi=+5E7O6gKMuJTUASA2=6eP=ngrxg@mail.gmail.com> (raw)
In-Reply-To: <BANLkTikgMMp+s+OBPdBCFPpXO6eztLD9uA@mail.gmail.com>
Hi Matt
I know only of an old thread about this
http://thread.gmane.org/gmane.emacs.orgmode/5145
Of course it would be very welcome and valuable for e. g. traveling
but I fear it is now too expensive to introduce. The trouble I see is
that the smallest possible first change has to include already almost
all of the work to be done in order to not break any of the many
things that are supported now and to hold on with backwards
compatibility. I hope that there are ideas that I can not imagine now,
how this could be broken down into reasonable parts.
Michael
On Sat, Apr 9, 2011 at 12:23, Matt Curtis <matt.r.curtis@gmail.com> wrote:
> Hello,
>
> I would like agenda timestamps to support time zones somehow, and I'm after
> some guidance from org-mode developers.
>
> My plan is to support the time offset +HHMM or -HHMM, at a minimum.
>
> After looking at the code I believe I need to modify org-agenda-get-timestamps
> quite heavily to effect this change.
>
> Currently it looks like it scans for timestamps which match the search date
> (YYYY-MM-DD), which would need to be changed to at least match adjacent
> days, and then filtered after applying the time zone offset, and
> finally adjusted
> with the offset to match local time.
>
> This would mean the agenda/list displays would get the same sort of results
> set, as the timestamps would be adjusted back to the search date - i.e. the
> search date would be considered "local time"; the change is to consider the
> offset when figuring out which items fall on this date.
>
> I have a couple of questions:
>
> * Is this a reasonable approach? (It would slow down agenda generation
> with the extra scanning and filtering)
>
> * If not, is there another design I can look at? (I wonder why this hasn't been
> done before, so I think maybe others have done some thinking about it.)
>
> * What parts of org-mode should I be looking at to ensure this change does
> not cause a regression?
next prev parent reply other threads:[~2011-04-09 15:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-09 10:23 Time zone support for agenda item timestamps Matt Curtis
2011-04-09 15:54 ` Michael Brand [this message]
2011-06-26 18:28 ` David Maus
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi=+5E7O6gKMuJTUASA2=6eP=ngrxg@mail.gmail.com' \
--to=michael.ch.brand@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=matt.r.curtis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).