From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Curtis Subject: Time zone support for agenda item timestamps Date: Sat, 9 Apr 2011 20:23:38 +1000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from [140.186.70.92] (port=39210 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8VKi-0007dY-OS for emacs-orgmode@gnu.org; Sat, 09 Apr 2011 06:24:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8VKh-00051E-LE for emacs-orgmode@gnu.org; Sat, 09 Apr 2011 06:24:00 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:47476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8VKh-000515-Gf for emacs-orgmode@gnu.org; Sat, 09 Apr 2011 06:23:59 -0400 Received: by wyf19 with SMTP id 19so4380119wyf.0 for ; Sat, 09 Apr 2011 03:23:58 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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? cheers, Matt