emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

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.


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?

  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 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:

  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 \
    --subject='Re: Time zone support for agenda item timestamps' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this 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).