Timezones revisited

Timezones revisited

[Russell Adams]

I understand that Org's timestamp format does not include timezone
information. Making that change would be an impractical modification.

I'm frequently working with several different timezones and I only
need to store a time stamp converted to my local time.

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.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Timezones revisited

[Eric Abrahamsen]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> I understand that Org's timestamp format does not include timezone
> information. Making that change would be an impractical modification.
>
> I'm frequently working with several different timezones and I only
> need to store a time stamp converted to my local time.
>
> 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.

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.

E

Re: Timezones revisited

[Russell Adams]

On Wed, Feb 01, 2017 at 07:50:24AM -0800, Eric Abrahamsen wrote:
> Russell Adams <RLAdams@AdamsInfoServ.Com> 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                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Timezones revisited

[Peter Neilson]

On Wed, 01 Feb 2017 10:50:24 -0500, Eric Abrahamsen  
<eric@ericabrahamsen.net> wrote:

> Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
>
>> I understand that Org's timestamp format does not include timezone
>> information. Making that change would be an impractical modification.
>>
>> I'm frequently working with several different timezones and I only
>> need to store a time stamp converted to my local time.
>>
>> 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.
>
> 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.
>
> E
Presumably everyone already knows that the timezones are more complicated  
than hoi polloi believe? The offsets are not always integer values of  
hours. For example, Newfoundland time is UTC−03:30. Additional  
complications include daylight saving time and the many historical  
versions of timezones. The definition of UTC can remain pretty much  
constant, but local-timezone time varies as a function of both location  
and calendar date.

Allowing user-defined functions (as simple or as complicated as one  
desires) for translation from UTC might be best.

Re: Timezones revisited

[Russell Adams]

On Wed, Feb 01, 2017 at 11:14:15AM -0500, Peter Neilson wrote:
> On Wed, 01 Feb 2017 10:50:24 -0500, Eric Abrahamsen
> Presumably everyone already knows that the timezones are more complicated
> than hoi polloi believe? The offsets are not always integer values of
> hours. For example, Newfoundland time is UTC−03:30. Additional
> complications include daylight saving time and the many historical
> versions of timezones. The definition of UTC can remain pretty much
> constant, but local-timezone time varies as a function of both location
> and calendar date.

Emacs has a timezone conversion function, which I assume pulls from
the tz info database like all the other system commands.

Local time zone should be the system time zone or one defined as a
per-buffer variable.

> Allowing user-defined functions (as simple or as complicated as one
> desires) for translation from UTC might be best.

I don't think we have to build anything from scratch. I think we just
need to take an extra TZ parameter in the input dialog and then run it
through the Emacs tz conversion function to get local time as the
final time we store.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Timezones revisited

[Eric Abrahamsen]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Wed, Feb 01, 2017 at 07:50:24AM -0800, Eric Abrahamsen wrote:
>> Russell Adams <RLAdams@AdamsInfoServ.Com> 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

Re: Timezones revisited

[Eric Abrahamsen]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Wed, Feb 01, 2017 at 11:14:15AM -0500, Peter Neilson wrote:
>> On Wed, 01 Feb 2017 10:50:24 -0500, Eric Abrahamsen
>> Presumably everyone already knows that the timezones are more complicated
>> than hoi polloi believe? The offsets are not always integer values of
>> hours. For example, Newfoundland time is UTC−03:30. Additional
>> complications include daylight saving time and the many historical
>> versions of timezones. The definition of UTC can remain pretty much
>> constant, but local-timezone time varies as a function of both location
>> and calendar date.
>
> Emacs has a timezone conversion function, which I assume pulls from
> the tz info database like all the other system commands.
>
> Local time zone should be the system time zone or one defined as a
> per-buffer variable.

Right, we'd be doing all our calculations based on the car of
`current-time-zone' (or the converted equivalent). I think that would
get us as close to "correct" as possible, and necessary.

Eric