Re: [O] Time-zone in dates

2015-07-08 Thread Don Armstrong
On Tue, 07 Jul 2015, Russell Adams wrote:
 On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote:
  I particularly like the single event (a flight) that requires more than
  one time zone to make sense.  My diary is chock full of cases where it
  looks like a flight out somewhere takes 2 hours but coming back takes
  11!  (strong winds ;-)
 
 I believe this doesn't disprove the need for storing in UTC.
[...]
 After all there's no data lost in the plane example other than the
 relative timezone of the observer.

The relative timezone of the observer is important, though, because
that's how you enter the information, and it's often the most logical
way to display the information. If you just store UTC there's no way to
regenerate that.

Though all of that said, just storing UTC is significantly easier, and
while I'd love to see a complete implementation, an incomplete
implementation which could be expanded to become complete would be a
great advance.

-- 
Don Armstrong  http://www.donarmstrong.com

This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_



Re: [O] Time-zone in dates

2015-07-07 Thread Don Armstrong
On Wed, 01 Jul 2015, Michael Brand wrote:
 On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote:
  On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
  In what way are you losing information?
 
  Sorry, should have been clear: the time zone information itself.  By
  reducing to UTC, you lose one bit of information.  Whether that matters
  or not in practice is not clear but I'm always uncomfortable when
  considering data representations that lead to information loss.
 
  I've been trying to come up with an example that would illustrate the
  problem but I've failed so far.
 
 As an example for the above I suggest to consider a non-stop flight
 with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both
 cities in different time zones, here intentionally even the same basic
 time zone but one with daylight saving and one without.

[...]

 2) When the Org file format would support time zones I would use
 
* Flight from Salt Lake City UT to Phoenix AZ
  2015-07-01 Wed 10:55 MDT--2015-07-01 Wed 11:26 MST
  - *Advantage*: Visibility of the time zones where the event takes
place.

Of course, this is even more complicated, as MST could mean UTC+08,
UTC-07 or UTC+06:30.

That said, lets not make perfect the enemy of the good. I've currently
got emacs running under TZ=America/Los_Angeles even though my machine
is in TZ=America/Chicago precisely because org mode can't yet handle
this.

I'd be willing to help out as much as I'm able, too.

-- 
Don Armstrong  http://www.donarmstrong.com

I have no use for before and after pictures.
I can't remember starting, and I'm never done.
 -- a softer world #221
http://www.asofterworld.com/index.php?id=221



[O] Timezone Support Status

2015-01-15 Thread Don Armstrong
Has anyone done any work into allowing for timezones to be specified in
timestamps (and maybe eventually, scheduling/deadlines) in org mode?

I know the last long thread about this in 2008[1] indicated that this
was unlikely to be supported, and a thread in 2011 just referred to the
same issue[2], pointing out that this would likely involve a fantastic
amount of work.

For me, being able to specify times in the file in UTC, and then
converting to the local timezone for everything else might be enough...
but I'd like to contribute to an existing effort/design if at all
possible.

1: http://thread.gmane.org/gmane.emacs.orgmode/5145
2: http://thread.gmane.org/gmane.emacs.orgmode/40732
-- 
Don Armstrong  http://www.donarmstrong.com

I'm So Meta, Even This Acronym
-- xkcd http://xkcd.com/917/