From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Timezones revisited Date: Wed, 01 Feb 2017 08:29:30 -0800 Message-ID: <87inotub6d.fsf@pellet> References: <20170131230346.GV7187@volibear.adamsinfoserv.com> <87shnxuczj.fsf@pellet> <20170201160541.GI7187@volibear.adamsinfoserv.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYxn7-0003Yn-Dg for emacs-orgmode@gnu.org; Wed, 01 Feb 2017 11:29:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYxn3-000481-CA for emacs-orgmode@gnu.org; Wed, 01 Feb 2017 11:29:53 -0500 Received: from [195.159.176.226] (port=45869 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYxn3-00047r-5A for emacs-orgmode@gnu.org; Wed, 01 Feb 2017 11:29:49 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cYxmr-00057N-NZ for emacs-orgmode@gnu.org; Wed, 01 Feb 2017 17:29:37 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Russell Adams writes: > On Wed, Feb 01, 2017 at 07:50:24AM -0800, Eric Abrahamsen wrote: >> Russell Adams writes: [...] >> Would it be completely out of the question to support an optional >> timezone marker? From (nth 1 (current-time-zone))? >> >> <2017-02-01 Wed PST> >> >> The plumbing for time calculations would be... an adventure. But it >> seems like it could be done in a backwards-compatible way. > > I gave some thought to the idea of storing all timestamps in GMT and > then each buffer could have a timezone defined or use the system > time. Then the relative time would be overlaid in viewing the > file. That's a real stretch though, as I think this would take > significant effort. I was envisioning an Agenda toggle between "show entries in my current timezone" (ie, the Germans say "we'll call you at 3pm!", the entry is input as 3pm "WET", and the Agenda shows you the appointment in your current time zone, which could be 10am or what have you), and "show entries in their local timezone" (ie, you make a bunch of appointments for next week in New York, and see them in their "real" times, with an "EST" tag, even though you're not there yet). Anyway this would be relatively simple compared to the problem time calculations and comparisons. I guess everything would need to get converted to UTC very early on, but memoized with information about the timezone offset. > I think for now a simple method to input a time from another timezone > and convert it to your own would suffice. That wouldn't change > anything regarding storage or working with timestamps, only a one time > conversion a the time of data entry. I wonder if that isn't a fast > change? That would be much simpler, but it wouldn't address traveling. If I schedule meetings for next week in another country, I would still run into the problem that if I do a caldav sync now, those meetings will display incorrectly on my phone when I get there. Also, the last time I looked into this, I couldn't find a user-friendly way of entering timezones. Ideally you'd be able to make use of the tzdata-style "America/Vancouver" notation, which would be great for text completion. I didn't see a cross-platform way of doing that. And making people enter the "PDT" notation seems impractical. Anyway, it's probably pie in the sky, but it sure would be nice. Eric