Time-zone in dates

Time-zone in dates

[Oleg Sivokon]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Left Right]

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

Re: Time-zone in dates

[J. David Boyd]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Nicolas Goaziou]

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

Re: Time-zone in dates

[francois]

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

Re: Time-zone in dates

[Nicolas Goaziou]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Nick Dokos]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Nick Dokos]

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?

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Michael Brand]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Russell Adams]

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

Re: Time-zone in dates

[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: Time-zone in dates

[Russell Adams]

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

Re: Time-zone in dates

[Eric S Fraga]

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

Re: Time-zone in dates

[Titus von der Malsburg]

[-- 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 --]

Re: Time-zone in dates

[Don Armstrong]

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

Re: Time-zone in dates

[Nick Dokos]

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

Re: Time-zone in dates

[Left Right]

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
>
>
>
>
>