"Thomas S. Dye" writes:
> No, I don't think you've missed anything significant. Thanks very much for
> your patience
> during a discussion that was interesting for me. I learned quite a bit from
> you and the
> other contributors to the thread and look forward now to learning how Org
> mode
Aloha Max,
Max Nikulin writes:
On 23/01/2023 23:04, Thomas S. Dye wrote:
* Kinds of event
- No-host event :: An event that takes place at an absolute
time. Participants
must know their local timezone offset from UTC. Example
[2023-01-23
06:00@UTC].
- Situated event :: An event that takes
On 23/01/2023 23:04, Thomas S. Dye wrote:
* Kinds of event
- No-host event :: An event that takes place at an absolute time.
Participants must know their local timezone offset from UTC. Example
[2023-01-23 06:00@UTC].
- Situated event :: An event that takes place at a time local to the
event
* Max Nikulin [2023-01-24 20:12]:
> On 22/01/2023 14:48, Tim Cross wrote:
> > Timestamp for a log
> > record I would probably want or one of the
> > variants because the most common way I use those types of timestamp is
> > in diagnosing problems and comparing revords from various locations
> >
* Max Nikulin [2023-01-24 07:51]:
> On 24/01/2023 09:44, Thomas S. Dye wrote:
> > Max Nikulin writes:
> > >
> > > I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests
> > > offset from UTC.
> >
> > Not for a casual programmer like me. The timestamp alone might easily be
> > read
Max Nikulin writes:
> On 22/01/2023 14:48, Tim Cross wrote:
>> Timestamp for a log
>> record I would probably want or one of the
>> variants because the most common way I use those types of timestamp is
>> in diagnosing problems and comparing revords from various locations
>> where I don't care
On 22/01/2023 14:48, Tim Cross wrote:
Timestamp for a log
record I would probably want or one of the
variants because the most common way I use those types of timestamp is
in diagnosing problems and comparing revords from various locations
where I don't care about the local time where the
Aloha Ihor,
Ihor Radchenko writes:
"Thomas S. Dye" writes:
I understand above that it is easier understandable when
reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I
guess
Max)
that user will understand that there is +11 hours ahead.
Yes, the offset here is
"Thomas S. Dye" writes:
>> I understand above that it is easier understandable when reading
>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess
>> Max)
>> that user will understand that there is +11 hours ahead.
>>
> Yes, the offset here is ambiguous--is it offset from some
On 24/01/2023 09:44, Thomas S. Dye wrote:
Max Nikulin writes:
I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests
offset from UTC.
Not for a casual programmer like me. The timestamp alone might easily be
read as 11 hours ahead of local time. Nevertheless, Org is certainly
Aloha Max,
Max Nikulin writes:
On 23/01/2023 23:04, Thomas S. Dye wrote:
I understand above that it is easier understandable when
reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I
guess Max)
that user will understand that there is +11 hours ahead.
Yes, the offset here is
On 23/01/2023 23:04, Thomas S. Dye wrote:
I understand above that it is easier understandable when reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max)
that user will understand that there is +11 hours ahead.
Yes, the offset here is ambiguous--is it offset from some
Aloha Jean Louis,
Jean Louis writes:
* Thomas S. Dye [2023-01-22 20:36]:
> After all, for a person in Berlin [2023-01-22 Sun
> 08:29@+1100] may
> tell more than [2023-01-22 Sun 08:29@Australia/Sydney].
I'm not sure to follow this. IIUC, the timestamp with offset
refers to
absolute time,
* Thomas S. Dye [2023-01-22 20:36]:
> > After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may
> > tell more than [2023-01-22 Sun 08:29@Australia/Sydney].
>
> I'm not sure to follow this. IIUC, the timestamp with offset refers to
> absolute time, whereas the timestamp with the
Aloha Max,
Max Nikulin writes:
Thomas, notice that I resumed a postponed earlier part of
discussion related to
timestamps in the past. Offset from UTC is almost always well
defined this case.
My perception is that discussing timestamps in future, we came
to agreement with
Tom that
Thomas, notice that I resumed a postponed earlier part of discussion
related to timestamps in the past. Offset from UTC is almost always well
defined this case.
My perception is that discussing timestamps in future, we came to
agreement with Tom that timestamps can be specified with timezone
Max Nikulin writes:
> On 22/01/2023 04:29, Tim Cross wrote:
>> Max Nikulin writes:
>>> - UTC is a recommendation for planning when participants are scattered over
>>> multiple
>>> timezones.
>>> - You admit that some timestamps in your files may be specified as time
>>> zone identifier +
>>>
Aloha Max,
Max Nikulin writes:
Let's consider the following timestamp
[2023-01-22 Sun 08:29@+1100]
"@" is unimportant here, I take it from Ihor's examples. This
timestamp is from
the "Date:" header of your message. It is not UTC, but in my
opinion it is
equally precise (disregarding
On 22/01/2023 04:29, Tim Cross wrote:
Max Nikulin writes:
- UTC is a recommendation for planning when participants are scattered over
multiple
timezones.
- You admit that some timestamps in your files may be specified as time zone
identifier +
local time relative to this zone.
- In both
19 matches
Mail list logo
