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
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 idea
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.
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 take
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
On Wed, 01 Jul 2015, Michael Brand wrote:
> On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga 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
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 someo
Eric S Fraga writes:
> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>> Eric S Fraga 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
>
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 F
Hi all
On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga 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 ma
On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
> Eric S Fraga 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 t
Eric S Fraga 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 us
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 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.
>
> Tim
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 A
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 of
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
Hello,
Eric S Fraga 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 wou
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 tel
Eric S Fraga 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 i
On Fri, Jun 26, 2015 at 5:12 PM, Eric S Fraga 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 r
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
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 que
23 matches
Mail list logo
