* Timezones revisited @ 2017-01-31 23:03 Russell Adams 2017-02-01 15:50 ` Eric Abrahamsen 0 siblings, 1 reply; 7+ messages in thread From: Russell Adams @ 2017-01-31 23:03 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-01-31 23:03 Timezones revisited Russell Adams @ 2017-02-01 15:50 ` Eric Abrahamsen 2017-02-01 16:05 ` Russell Adams 2017-02-01 16:14 ` Peter Neilson 0 siblings, 2 replies; 7+ messages in thread From: Eric Abrahamsen @ 2017-02-01 15:50 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-02-01 15:50 ` Eric Abrahamsen @ 2017-02-01 16:05 ` Russell Adams 2017-02-01 16:29 ` Eric Abrahamsen 2017-02-01 16:14 ` Peter Neilson 1 sibling, 1 reply; 7+ messages in thread From: Russell Adams @ 2017-02-01 16:05 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-02-01 16:05 ` Russell Adams @ 2017-02-01 16:29 ` Eric Abrahamsen 0 siblings, 0 replies; 7+ messages in thread From: Eric Abrahamsen @ 2017-02-01 16:29 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-02-01 15:50 ` Eric Abrahamsen 2017-02-01 16:05 ` Russell Adams @ 2017-02-01 16:14 ` Peter Neilson 2017-02-01 16:20 ` Russell Adams 1 sibling, 1 reply; 7+ messages in thread From: Peter Neilson @ 2017-02-01 16:14 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-02-01 16:14 ` Peter Neilson @ 2017-02-01 16:20 ` Russell Adams 2017-02-01 17:33 ` Eric Abrahamsen 0 siblings, 1 reply; 7+ messages in thread From: Russell Adams @ 2017-02-01 16:20 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Timezones revisited 2017-02-01 16:20 ` Russell Adams @ 2017-02-01 17:33 ` Eric Abrahamsen 0 siblings, 0 replies; 7+ messages in thread From: Eric Abrahamsen @ 2017-02-01 17:33 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-01 17:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-31 23:03 Timezones revisited Russell Adams 2017-02-01 15:50 ` Eric Abrahamsen 2017-02-01 16:05 ` Russell Adams 2017-02-01 16:29 ` Eric Abrahamsen 2017-02-01 16:14 ` Peter Neilson 2017-02-01 16:20 ` Russell Adams 2017-02-01 17:33 ` Eric Abrahamsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).