* Time-zone in dates
@ 2015-06-26 13:40 Oleg Sivokon
2015-06-26 14:12 ` Eric S Fraga
0 siblings, 1 reply; 23+ messages in thread
From: Oleg Sivokon @ 2015-06-26 13:40 UTC (permalink / raw)
To: emacs-orgmode
Hello, list.
I was looking for a way to add time-zone to the date recrod, something
like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely
that the functionality isn't there, so I wonder if it's really so, and
if indeed so, then what would it take to add it?
I've asked the same question here:
http://emacs.stackexchange.com/questions/13463/specify-timezone-in-org-date-format
just in case you saw it earlier.
Best.
Oleg
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 13:40 Time-zone in dates Oleg Sivokon
@ 2015-06-26 14:12 ` Eric S Fraga
2015-06-26 14:33 ` Left Right
2015-06-26 14:38 ` J. David Boyd
0 siblings, 2 replies; 23+ messages in thread
From: Eric S Fraga @ 2015-06-26 14:12 UTC (permalink / raw)
To: Oleg Sivokon; +Cc: emacs-orgmode
On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote:
> Hello, list.
>
> I was looking for a way to add time-zone to the date recrod, something
> like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely
> that the functionality isn't there, so I wonder if it's really so, and
> if indeed so, then what would it take to add it?
It is indeed so. What would it take? Somebody to program the
functionality in but this is a major challenge as time stamps are a
fundamental building block of org and it would likely need to be upwards
compatible...
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 14:12 ` Eric S Fraga
@ 2015-06-26 14:33 ` Left Right
2015-06-26 14:38 ` J. David Boyd
1 sibling, 0 replies; 23+ messages in thread
From: Left Right @ 2015-06-26 14:33 UTC (permalink / raw)
To: Oleg Sivokon, emacs-orgmode
On Fri, Jun 26, 2015 at 5:12 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Somebody to program the
> functionality in but this is a major challenge as time stamps are a
> fundamental building block of org and it would likely need to be upwards
> compatible...
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3
Thanks for the info, Eric. I imagined this wouldn't be easy, but I
would be interested to know whether there might be some suggestions,
possibly to split the work up into stages. For example, perhaps, at
first one could only live with dates typed in in that format, but the
calendar wouldn't offer an interface to input them. Perhaps there
could be even more fine-grained stages. I'm also not entirely sure,
but I have a feeling that that might be a problem as well: does
interoperability with Calc require certain date format? Would Calc
have to also have to support this, once added?
Thanks.
Oleg
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 14:12 ` Eric S Fraga
2015-06-26 14:33 ` Left Right
@ 2015-06-26 14:38 ` J. David Boyd
2015-06-26 15:10 ` Eric S Fraga
1 sibling, 1 reply; 23+ messages in thread
From: J. David Boyd @ 2015-06-26 14:38 UTC (permalink / raw)
To: emacs-orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote:
>> Hello, list.
>>
>> I was looking for a way to add time-zone to the date recrod, something
>> like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely
>> that the functionality isn't there, so I wonder if it's really so, and
>> if indeed so, then what would it take to add it?
>
> It is indeed so. What would it take? Somebody to program the
> functionality in but this is a major challenge as time stamps are a
> fundamental building block of org and it would likely need to be upwards
> compatible...
I can see that being a real pain. The simple way would 'just' be to convert
everything to UTC in the background for comparison.
Nothing I want to do!
Dave
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 14:38 ` J. David Boyd
@ 2015-06-26 15:10 ` Eric S Fraga
2015-06-26 19:20 ` Nicolas Goaziou
0 siblings, 1 reply; 23+ messages in thread
From: Eric S Fraga @ 2015-06-26 15:10 UTC (permalink / raw)
To: J. David Boyd; +Cc: emacs-orgmode
On Friday, 26 Jun 2015 at 10:38, J. David Boyd wrote:
[...]
> I can see that being a real pain. The simple way would 'just' be to convert
> everything to UTC in the background for comparison.
Having spent a year essentially commuting between Australia and the UK a
couple of years ago, I can tell you that there is no "simple"
solution... :(
The simplest solution for me was firstly to use org (of course :-), then
put in all time stamps as "local" time and finally ensure that the time
zone setting for the computer itself, e.g. a laptop, matched where I was
at the time. This turns out to be more human oriented than having to
worry about time zones, especially when it comes to extra complications
like summer time.
In practice, I do not miss having time zone information in org.
YMMV, of course!
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 15:10 ` Eric S Fraga
@ 2015-06-26 19:20 ` Nicolas Goaziou
2015-06-26 19:57 ` francois
0 siblings, 1 reply; 23+ messages in thread
From: Nicolas Goaziou @ 2015-06-26 19:20 UTC (permalink / raw)
To: J. David Boyd; +Cc: emacs-orgmode
Hello,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> In practice, I do not miss having time zone information in org.
Time zone information is interesting when users of different areas are
exchanging Org documents.
I think it would be useful to have:
- a keyword to specify time zone per document. This time zone would
apply to every time stamp not defining their own time zone. Default
value could be `local' so we would be backward compatible.
- a way to specify a time zone per time stamp, overriding the previous
keyword.
I think it would require to define a proper API for timestamps in order
to ensure, e.g., comparisons are done right.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 19:20 ` Nicolas Goaziou
@ 2015-06-26 19:57 ` francois
2015-06-26 21:48 ` Nicolas Goaziou
2015-06-29 13:17 ` Eric S Fraga
0 siblings, 2 replies; 23+ messages in thread
From: francois @ 2015-06-26 19:57 UTC (permalink / raw)
To: emacs-orgmode
Hello,
On Fri, Jun 26, 2015 at 09:20:00PM +0200, Nicolas Goaziou wrote:
> Time zone information is interesting when users of different areas are
> exchanging Org documents.
>
> I think it would be useful to have:
>
> - a keyword to specify time zone per document. This time zone would
> apply to every time stamp not defining their own time zone. Default
> value could be `local' so we would be backward compatible.
>
> - a way to specify a time zone per time stamp, overriding the previous
> keyword.
>
> I think it would require to define a proper API for timestamps in order
> to ensure, e.g., comparisons are done right.
Timezones are strange beasts to deal with.
It is really simpler programmatically to deal with time offsets
instead. The downside is that you cannot manage DST and other similar
peculiarities but the API is much simpler to write.
Just please don't confuse timezones and time offsets especially in
documentation as it is not the same thing and it can lead to
confusion.
I reread from time to time this note from W3C which explains the
difference and why it matters :
http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226
Regards,
François
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 19:57 ` francois
@ 2015-06-26 21:48 ` Nicolas Goaziou
2015-06-29 13:17 ` Eric S Fraga
1 sibling, 0 replies; 23+ messages in thread
From: Nicolas Goaziou @ 2015-06-26 21:48 UTC (permalink / raw)
To: francois; +Cc: emacs-orgmode
Hello,
francois@avalenn.eu writes:
> Timezones are strange beasts to deal with.
True.
> It is really simpler programmatically to deal with time offsets
> instead. The downside is that you cannot manage DST and other similar
> peculiarities but the API is much simpler to write.
However, time offsets are not very interesting. Org is (also) about
appointments, deadlines... so timezones are more accurate.
Also, Emacs contains "timezone.el", which, I assume, should take care of
all the heavy duty concerning these beasts, as far as an API is
concerned.
This requires care, but it should be doable, really, don't you think?
> Just please don't confuse timezones and time offsets especially in
> documentation as it is not the same thing and it can lead to
> confusion.
>
> I reread from time to time this note from W3C which explains the
> difference and why it matters :
> http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226
Thank you for the reference. I didn't know about it.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-26 19:57 ` francois
2015-06-26 21:48 ` Nicolas Goaziou
@ 2015-06-29 13:17 ` Eric S Fraga
2015-06-30 1:17 ` Nick Dokos
1 sibling, 1 reply; 23+ messages in thread
From: Eric S Fraga @ 2015-06-29 13:17 UTC (permalink / raw)
To: francois; +Cc: emacs-orgmode
On Friday, 26 Jun 2015 at 21:57, francois@avalenn.eu wrote:
[...]
> It is really simpler programmatically to deal with time offsets
> instead. The downside is that you cannot manage DST and other similar
> peculiarities but the API is much simpler to write.
Time offsets are not sufficient. My Australia experience involved me
living in South Australia while working with colleagues in the UK. The
time difference throughout the year was one of 8.5 hours, 9.5 hours or
10.5 hours, depending on the various switches to and from daylight
savings. Very annoying and confusing to manage...
To be effective and usable, org will need to incorporate time zone
information.
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1253-gaa9c4b
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-29 13:17 ` Eric S Fraga
@ 2015-06-30 1:17 ` Nick Dokos
2015-06-30 7:36 ` Eric S Fraga
0 siblings, 1 reply; 23+ messages in thread
From: Nick Dokos @ 2015-06-30 1:17 UTC (permalink / raw)
To: emacs-orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Friday, 26 Jun 2015 at 21:57, francois@avalenn.eu wrote:
>
> [...]
>
>> It is really simpler programmatically to deal with time offsets
>> instead. The downside is that you cannot manage DST and other similar
>> peculiarities but the API is much simpler to write.
>
> Time offsets are not sufficient. My Australia experience involved me
> living in South Australia while working with colleagues in the UK. The
> time difference throughout the year was one of 8.5 hours, 9.5 hours or
> 10.5 hours, depending on the various switches to and from daylight
> savings. Very annoying and confusing to manage...
>
> To be effective and usable, org will need to incorporate time zone
> information.
The only reliable way of doing that is to use UTC as the "internal"
representation and translate to/from local time on external
display/input *only*. In the case of org mode, the "internal"
representation is user-visible, so that can cause confusion and some
head-scratching. But *any* other method is going to be a nightmare
(damhikt).
--
Nick
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-30 1:17 ` Nick Dokos
@ 2015-06-30 7:36 ` Eric S Fraga
2015-06-30 15:08 ` Nick Dokos
0 siblings, 1 reply; 23+ messages in thread
From: Eric S Fraga @ 2015-06-30 7:36 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
> The only reliable way of doing that is to use UTC as the "internal"
> representation and translate to/from local time on external
> display/input *only*. In the case of org mode, the "internal"
> representation is user-visible, so that can cause confusion and some
> head-scratching. But *any* other method is going to be a nightmare
> (damhikt).
This may be the correct approach although I worry about losing
information by only storing UTC. Whether this information loss is
important or not is difficult to predict. It may be of ephemeral
importance only.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1261-g304f84
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-30 7:36 ` Eric S Fraga
@ 2015-06-30 15:08 ` Nick Dokos
2015-07-01 6:27 ` Eric S Fraga
0 siblings, 1 reply; 23+ messages in thread
From: Nick Dokos @ 2015-06-30 15:08 UTC (permalink / raw)
To: emacs-orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
>> The only reliable way of doing that is to use UTC as the "internal"
>> representation and translate to/from local time on external
>> display/input *only*. In the case of org mode, the "internal"
>> representation is user-visible, so that can cause confusion and some
>> head-scratching. But *any* other method is going to be a nightmare
>> (damhikt).
>
> This may be the correct approach although I worry about losing
> information by only storing UTC. Whether this information loss is
> important or not is difficult to predict. It may be of ephemeral
> importance only.
In what way are you losing information?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-06-30 15:08 ` Nick Dokos
@ 2015-07-01 6:27 ` Eric S Fraga
2015-07-01 10:04 ` Michael Brand
2015-07-01 15:17 ` Nick Dokos
0 siblings, 2 replies; 23+ messages in thread
From: Eric S Fraga @ 2015-07-01 6:27 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
>>> The only reliable way of doing that is to use UTC as the "internal"
>>> representation and translate to/from local time on external
>>> display/input *only*. In the case of org mode, the "internal"
>>> representation is user-visible, so that can cause confusion and some
>>> head-scratching. But *any* other method is going to be a nightmare
>>> (damhikt).
>>
>> This may be the correct approach although I worry about losing
>> information by only storing UTC. Whether this information loss is
>> important or not is difficult to predict. It may be of ephemeral
>> importance only.
>
> 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.
Funnily enough, the one example I can think of that would be difficult
to manage with UTC is the case of not wanting to specify a time
zone. Somewhat contrived but, for instance, wanting to do something
every morning such as brushing my teeth. This would be, say, at 7am
regardless of which time zone I'm in. If this were stored in UTC, it
would be at a different time depending on where I was at the time.
Enough rambling for the morning. Time to get some work done! :)
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 6:27 ` Eric S Fraga
@ 2015-07-01 10:04 ` Michael Brand
2015-07-01 11:22 ` Eric S Fraga
2015-07-07 17:14 ` Don Armstrong
2015-07-01 15:17 ` Nick Dokos
1 sibling, 2 replies; 23+ messages in thread
From: Michael Brand @ 2015-07-01 10:04 UTC (permalink / raw)
To: Org Mode
Hi all
On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga <e.fraga@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.
> Funnily enough, the one example I can think of that would be difficult
> to manage with UTC is the case of not wanting to specify a time
> zone. Somewhat contrived but, for instance, wanting to do something
> every morning such as brushing my teeth. This would be, say, at 7am
> regardless of which time zone I'm in. If this were stored in UTC, it
> would be at a different time depending on where I was at the time.
As an example for the above I suggest to consider noon as an event
bound enough to local time.
Furthermore, e. g. astronomical events can serve as examples not bound
to locality. Or for Eric: A telepresence meeting with the team in
South Australia and the team in UK that is in one single global Org
agenda file shared between the teams.
1) Current Org that supports only local time without time zone
* Flight from Salt Lake City UT to Phoenix AZ
<2015-07-01 Wed 10:55>--<2015-07-01 Wed 11:26>
- *Problem*: Valid only in matching local time zone, here MDT and
MST.
* Next noon
<2015-07-01 Wed 12:00>
* Next new moon
<2015-07-16 Thu 03:24>
- *Problem*: Valid only in matching local time zone, here CEST.
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.
* Next noon
<2015-07-01 Wed 12:00>
* Next new moon
<2015-07-16 Thu 01:24 UTC>
- *Advantage*: Visibility of neutrality regarding time zones.
All three examples are convertible to all local time zones.
3) When the Org file format would not support different time zones but
only UTC and Org would support only conversions from and to current
local time for display and input then it is not visible that
departure and arrival are in different time zones and in which time
zones they are
* Flight from Salt Lake City UT to Phoenix AZ
<2015-07-01 Wed 16:55 UTC>--<2015-07-01 Wed 18:26 UTC>
* Next noon
<2015-07-01 Wed 10:00 UTC>
- *Problem*: Valid only in matching local time zone, here CEST.
* Next new moon
<2015-07-16 Thu 01:24 UTC>
Time zones used in the examples
- MST :: Mountain Standard Time / Mountain Time (Standard Time), UTC-0700
- MDT :: Mountain Daylight Time (Daylight Saving Time), UTC-0600
- CEST :: Central European Summer Time (Daylight Saving Time), UTC+0200
Michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 10:04 ` Michael Brand
@ 2015-07-01 11:22 ` Eric S Fraga
2015-07-07 17:27 ` Russell Adams
2015-07-07 17:14 ` Don Armstrong
1 sibling, 1 reply; 23+ messages in thread
From: Eric S Fraga @ 2015-07-01 11:22 UTC (permalink / raw)
To: Michael Brand; +Cc: Org Mode
Michael,
thanks for some brilliant use cases!
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 ;-)
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 6:27 ` Eric S Fraga
2015-07-01 10:04 ` Michael Brand
@ 2015-07-01 15:17 ` Nick Dokos
2015-07-01 22:17 ` Left Right
1 sibling, 1 reply; 23+ messages in thread
From: Nick Dokos @ 2015-07-01 15:17 UTC (permalink / raw)
To: emacs-orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>
>>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
>>>> The only reliable way of doing that is to use UTC as the "internal"
>>>> representation and translate to/from local time on external
>>>> display/input *only*. In the case of org mode, the "internal"
>>>> representation is user-visible, so that can cause confusion and some
>>>> head-scratching. But *any* other method is going to be a nightmare
>>>> (damhikt).
>>>
>>> This may be the correct approach although I worry about losing
>>> information by only storing UTC. Whether this information loss is
>>> important or not is difficult to predict. It may be of ephemeral
>>> importance only.
>>
>> 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.
>
> Funnily enough, the one example I can think of that would be difficult
> to manage with UTC is the case of not wanting to specify a time
> zone. Somewhat contrived but, for instance, wanting to do something
> every morning such as brushing my teeth. This would be, say, at 7am
> regardless of which time zone I'm in. If this were stored in UTC, it
> would be at a different time depending on where I was at the time.
>
This is actually a pretty good example. This and Michael Brand's examples
make it clear that storing (just) UTC in the file is untenable.
Nick
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 15:17 ` Nick Dokos
@ 2015-07-01 22:17 ` Left Right
0 siblings, 0 replies; 23+ messages in thread
From: Left Right @ 2015-07-01 22:17 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
My initial case was very similar to the one Michael described in the
telepresence example, except that in my case, I need to assign shifts
to people living in different timezones. I.e. I need to make sure that
a shift assigned to someone in Illinois will end at the same time when
the shift of someone from California begins. One way of doing this is
to set all times in UTC+0, but some of us (especially myself :) live
very close to UTC+0, so I can accidentally confuse my local time with
the universal time. It would be also nicer if shifts were in the local
time of people assigned to them too.
On Wed, Jul 1, 2015 at 6:17 PM, Nick Dokos <ndokos@gmail.com> wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>>
>>>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
>>>>> The only reliable way of doing that is to use UTC as the "internal"
>>>>> representation and translate to/from local time on external
>>>>> display/input *only*. In the case of org mode, the "internal"
>>>>> representation is user-visible, so that can cause confusion and some
>>>>> head-scratching. But *any* other method is going to be a nightmare
>>>>> (damhikt).
>>>>
>>>> This may be the correct approach although I worry about losing
>>>> information by only storing UTC. Whether this information loss is
>>>> important or not is difficult to predict. It may be of ephemeral
>>>> importance only.
>>>
>>> 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.
>>
>> Funnily enough, the one example I can think of that would be difficult
>> to manage with UTC is the case of not wanting to specify a time
>> zone. Somewhat contrived but, for instance, wanting to do something
>> every morning such as brushing my teeth. This would be, say, at 7am
>> regardless of which time zone I'm in. If this were stored in UTC, it
>> would be at a different time depending on where I was at the time.
>>
>
> This is actually a pretty good example. This and Michael Brand's examples
> make it clear that storing (just) UTC in the file is untenable.
>
> Nick
>
>
>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 10:04 ` Michael Brand
2015-07-01 11:22 ` Eric S Fraga
@ 2015-07-07 17:14 ` Don Armstrong
1 sibling, 0 replies; 23+ messages in thread
From: Don Armstrong @ 2015-07-07 17:14 UTC (permalink / raw)
To: emacs-orgmode
On Wed, 01 Jul 2015, Michael Brand wrote:
> On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga <e.fraga@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-01 11:22 ` Eric S Fraga
@ 2015-07-07 17:27 ` Russell Adams
2015-07-08 15:59 ` Don Armstrong
0 siblings, 1 reply; 23+ messages in thread
From: Russell Adams @ 2015-07-07 17:27 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Michael Brand
On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote:
> Michael,
>
> thanks for some brilliant use cases!
>
> 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 ;-)
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
>
I believe this doesn't disprove the need for storing in UTC.
I just think it means that you need a display filter that can specify
a timezone. It sounds like most of your times will be correct using
your system time, and if you have something that needs to be
displayed in a different timezone, specify it for that one entry.
After all there's no data lost in the plane example other than the
relative timezone of the observer. The duration is fixed, and the UTC
times are exact. Only the observer changes timezone.
------------------------------------------------------------------
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] 23+ messages in thread
* Re: Time-zone in dates
2015-07-07 17:27 ` Russell Adams
@ 2015-07-08 15:59 ` Don Armstrong
2015-07-08 16:16 ` Russell Adams
0 siblings, 1 reply; 23+ messages in thread
From: Don Armstrong @ 2015-07-08 15:59 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Michael Brand
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_
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-08 15:59 ` Don Armstrong
@ 2015-07-08 16:16 ` Russell Adams
2015-07-08 16:40 ` Eric S Fraga
0 siblings, 1 reply; 23+ messages in thread
From: Russell Adams @ 2015-07-08 16:16 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Michael Brand
On Wed, Jul 08, 2015 at 10:59:54AM -0500, Don Armstrong wrote:
> 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.
I'd suggest that the relative timezone of the observer is normally the
same, and if it should differ a display override sounds appropriate.
> 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.
I think the question is would supporting timezones be difficult to add?
Then would you store the time in UTC only, or support a full timestamp
that included timezone?
Finally when being displayed they can use the user's $TZ by default,
and maybe a suffix of @ TZ inside the date syntax?
------------------------------------------------------------------
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] 23+ messages in thread
* Re: Time-zone in dates
2015-07-08 16:16 ` Russell Adams
@ 2015-07-08 16:40 ` Eric S Fraga
2015-07-08 17:22 ` Titus von der Malsburg
0 siblings, 1 reply; 23+ messages in thread
From: Eric S Fraga @ 2015-07-08 16:40 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Michael Brand
On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote:
[...]
> Then would you store the time in UTC only, or support a full timestamp
> that included timezone?
>
> Finally when being displayed they can use the user's $TZ by default,
> and maybe a suffix of @ TZ inside the date syntax?
The ideal implementation, in my opinion, would have time stamps defined
& stored with time zone information, as given by the user when creating
them (although this could default to UTC, say, if not present in the
time stamp) but displayed according to the user's $TZ (or overridden
with emacs variable) in cases like agenda views.
For upwards compatibility, however, it might be best if time stamps with
no time zone information be considered to be at the user's timezone,
as it is now.
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates
2015-07-08 16:40 ` Eric S Fraga
@ 2015-07-08 17:22 ` Titus von der Malsburg
0 siblings, 0 replies; 23+ messages in thread
From: Titus von der Malsburg @ 2015-07-08 17:22 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Michael Brand, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On 2015-07-08 Wed 09:40, Eric S Fraga wrote:
> On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote:
>
> [...]
>
>> Then would you store the time in UTC only, or support a full timestamp
>> that included timezone?
>>
>> Finally when being displayed they can use the user's $TZ by default,
>> and maybe a suffix of @ TZ inside the date syntax?
>
> The ideal implementation, in my opinion, would have time stamps defined
> & stored with time zone information, as given by the user when creating
> them (although this could default to UTC, say, if not present in the
> time stamp) but displayed according to the user's $TZ (or overridden
> with emacs variable) in cases like agenda views.
I like this proposal because it solves the problem at hand (as far as I
can tell) but isn’t over-engineered. I also like that the date string
that the user sees would be the string stored in the file, at least in
the default case (non-agenda view). The mostly literal display of files
is what sets org-mode apart from other outlines because that allows
users to take full advantage of Emacs’ powerful text editing
capabilities.
> For upwards compatibility, however, it might be best if time stamps with
> no time zone information be considered to be at the user's timezone,
> as it is now.
This point is important. Whatever the solution is it should not break
documents and workflows for users who don’t care about time zones. I
agree that time zones are important for some people but let’s face it,
org-mode made it thus far without support time zones, which suggests
that it’s not that big of a deal for most users.
Titus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-07-08 17:22 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-26 13:40 Time-zone in dates Oleg Sivokon
2015-06-26 14:12 ` Eric S Fraga
2015-06-26 14:33 ` Left Right
2015-06-26 14:38 ` J. David Boyd
2015-06-26 15:10 ` Eric S Fraga
2015-06-26 19:20 ` Nicolas Goaziou
2015-06-26 19:57 ` francois
2015-06-26 21:48 ` Nicolas Goaziou
2015-06-29 13:17 ` Eric S Fraga
2015-06-30 1:17 ` Nick Dokos
2015-06-30 7:36 ` Eric S Fraga
2015-06-30 15:08 ` Nick Dokos
2015-07-01 6:27 ` Eric S Fraga
2015-07-01 10:04 ` Michael Brand
2015-07-01 11:22 ` Eric S Fraga
2015-07-07 17:27 ` Russell Adams
2015-07-08 15:59 ` Don Armstrong
2015-07-08 16:16 ` Russell Adams
2015-07-08 16:40 ` Eric S Fraga
2015-07-08 17:22 ` Titus von der Malsburg
2015-07-07 17:14 ` Don Armstrong
2015-07-01 15:17 ` Nick Dokos
2015-07-01 22:17 ` Left Right
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).