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
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
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
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
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
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
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.
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
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
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
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*.
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
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
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
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.
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
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,
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
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
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.
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
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
22 matches
Mail list logo
