[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Timezones revisited
From: |
Russell Adams |
Subject: |
Re: [O] Timezones revisited |
Date: |
Wed, 1 Feb 2017 17:05:41 +0100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Wed, Feb 01, 2017 at 07:50:24AM -0800, Eric Abrahamsen wrote:
> Russell Adams <address@hidden> writes:
> >
> > Does the time stamp input support some form of timezone input? I
> > checked the manual and tried a few methods and they don't appear
> > supported.
>
> If the time stamp format doesn't support timezone info, then the input
> method won't either, unfortunately. I had one of my occasional attacks
> of enthusiasm about this subject recently -- using org-caldav while
> you're traveling really exposes the limitations of timezone-unaware
> scheduling.
That's my case. Now I'm using the date command with -d to translate
for me.
> 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 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?
Thanks.
------------------------------------------------------------------
Russell Adams address@hidden
PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3