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-08 Thread 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 Adamsrlad...@adamsinfoserv.com

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

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



Re: [O] Time-zone in dates

2015-07-08 Thread 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: [O] Time-zone in dates

2015-07-08 Thread Titus von der Malsburg

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



signature.asc
Description: PGP signature


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



Re: [O] Time-zone in dates

2015-07-07 Thread 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 Adamsrlad...@adamsinfoserv.com

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

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



Re: [O] Time-zone in dates

2015-07-01 Thread Michael Brand
Hi all

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.

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

2015-07-01 Thread 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: [O] Time-zone in dates

2015-07-01 Thread Nick Dokos
Eric S Fraga e.fr...@ucl.ac.uk writes:

 On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
 Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-07-01 Thread 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 ndo...@gmail.com wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
 Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-07-01 Thread Eric S Fraga
On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
 Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-06-30 Thread 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: [O] Time-zone in dates

2015-06-30 Thread Nick Dokos
Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-06-29 Thread Eric S Fraga
On Friday, 26 Jun 2015 at 21:57, franc...@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: [O] Time-zone in dates

2015-06-29 Thread Nick Dokos
Eric S Fraga e.fr...@ucl.ac.uk writes:

 On Friday, 26 Jun 2015 at 21:57, franc...@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




[O] Time-zone in dates

2015-06-26 Thread 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: [O] Time-zone in dates

2015-06-26 Thread J. David Boyd
Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-06-26 Thread 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: [O] Time-zone in dates

2015-06-26 Thread Left Right
On Fri, Jun 26, 2015 at 5:12 PM, Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-06-26 Thread 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: [O] Time-zone in dates

2015-06-26 Thread Nicolas Goaziou
Hello,

Eric S Fraga e.fr...@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: [O] Time-zone in dates

2015-06-26 Thread 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: [O] Time-zone in dates

2015-06-26 Thread Nicolas Goaziou
Hello,

franc...@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