* Max Nikulin [2023-01-31 11:16]:
> On 31/01/2023 14:04, Jean Louis wrote:
> > I have given facts, and references with the sole intention to help in
> > understanding so that Org programmers do not start relying on UTC
> > offset alone, as that is not how other programs work.
>
> From my point of
On 31/01/2023 14:04, Jean Louis wrote:
I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.
From my point of view at the beginning you were promoting that Org
Dear Heinz,
Thanks, let me see.
* Heinz Tuechler [2023-01-31 01:02]:
> Dear Jean Louis,
>
> it appears to me that you mix two aspects. I agree with you that a time
> zone needs an offset from UTC to be defined. Consequently the definition
> of a time zone requires an offset.
Yes, that is good
* Tim Cross [2023-01-31 01:05]:
> Jean,
>
> you have a very irritating habit of changing the topic of the discussion
> in order to push whatever you feel you want to argue about. My response
> to you had nothing to do with all the irrelevant points you insist on
> repeating despite numerous attem
Aloha Jean Louis,
Jean Louis writes:
Dear Thomas,
I give my best to find references for you and explain you the
possible
problem in calculation of time stamps. That problems exist is
clear.
To solve problem it is important to first define it. And when
there
are developers reading it, I w
Jean Louis writes:
> * Tim Cross [2023-01-29 23:38]:
>> Saying that an offset is a fixed value is very different from saying
>> that a time zone has a fixed offset. I think this is where your
>> confusion is coming from.
>
> I said neither of those. I never said that UTC offset is fixed. I am
>
* Tim Cross [2023-01-29 23:38]:
> Yes, a timezone is defined by the offset it has from UTC
Other way around Tim, the UTC offset is defined for the time zone.
Time zone is not derived fro UTC offset, that does not work. UTC
offset is derived from time zone.
> Yes, a location time zone may change
* Max Nikulin [2023-01-29 09:33]:
> On 29/01/2023 11:09, Jean Louis wrote:
> > * Tim Cross [2023-01-28 00:15]:
> > > > > • Offset (fixed)
> > > > >• This captures the idea of "when did it happen for the person who
> ^^^
> Jean, you missed it.
Dear Thomas,
I give my best to find references for you and explain you the possible
problem in calculation of time stamps. That problems exist is clear.
To solve problem it is important to first define it. And when there
are developers reading it, I wish to provide best possible references
for th
* Max Nikulin [2023-01-29 09:33]:
> On 29/01/2023 11:09, Jean Louis wrote:
> > * Tim Cross [2023-01-28 00:15]:
> > > > > • Offset (fixed)
> > > > >• This captures the idea of "when did it happen for the person who
> ^^^
> Jean, you missed it.
Ihor, makes sense. that we probably need to *display* imprecision
doesn't mean we need to accept/parse it.
Greg Minshall writes:
> i guess the third is what "2004-06~" might mean (i visualize, in
> amusement, a very light pink background over all of June, with some
> decay function coming earlier into May, later into July :).
Maybe. But my point states - it is not trivial thing to implement.
For cont
Ihor,
> That's all nice but what a headache will it be to implement. What will
> 2004-06~ mean for agenda, for example?
i don't know the specific "2004-06~", but i do think that for the agenda
(i assume), being able to express ambiguity to the user will be
important. as people have pointed out (
Sterling Hooten writes:
>> And we need to deviate from ISO 8601 anyway. At least, because it does
>> not define time zones, only absolute UTC offsets. So, the ability to
>> conform with the existing formats remains questionable.
>
> This is correct for the 2019 version of the ISO 8601.
>
> From m
Sterling Hooten writes:
> This is an initial glossary compiled from various standards and sources;
> it's incomplete, probably incorrect, and open to critique, but is useful
> in articulating a possible road map forward.
Do I understand correctly that the terms are simply taken from ISO
(https:
Ihor, Sterling, et al.,
just a thought/reminder. there are "semantics" and "encoding". a spec
like ISO-8601 specifies both. the important thing for org-mode is to
use an encoding that
1. is easily parsable/understandable by the mere mortal
2. allows expression of all the semantics of the unde
Jean Louis writes:
> * Tim Cross [2023-01-28 00:15]:
>> >
>> >> What kinds of representations would a calendar system capable of
>> >> handling timezones require?
>> >>
>> >> • Instant (fixed)
>> >> • This is referring to an unambiguous moment in time
>> >> • e.g., 2007-02-03T05:00:00.000Z
Daryl Manning writes:
> All these discussions are really great, devil is in the details and all,
> but is anyone working on implementation code for this? It’s tricky to have
> visibility on WIP on org-mode - probs just me not knowing where to look tbh
> (but big believer that working code is prog
All these discussions are really great, devil is in the details and all,
but is anyone working on implementation code for this? It’s tricky to have
visibility on WIP on org-mode - probs just me not knowing where to look tbh
(but big believer that working code is progress… 😊)
Daryl.
On Sun, 29 Jan
Jean Louis writes:
Time offset does not independently exists without time zone.
While you
represent it without time zone, you have to observe time zone
first,
before deriving time offset from it.
UTC offset exists without time zone. UTC is absolute time and
offsets from it do not refer
On 29/01/2023 11:09, Jean Louis wrote:
* Tim Cross [2023-01-28 00:15]:
• Offset (fixed)
• This captures the idea of "when did it happen for the person who
^^^
Jean, you missed it.
made the observation"
• e.g., 2007-02-03T04:00:00.
* Tim Cross [2023-01-28 00:15]:
> >
> >> What kinds of representations would a calendar system capable of
> >> handling timezones require?
> >>
> >> • Instant (fixed)
> >> • This is referring to an unambiguous moment in time
> >> • e.g., 2007-02-03T05:00:00.000Z
> >> • Offset (fixed)
> >> •
Sterling, thank you very much for the list of references. I was not
aware of EDTF activity or the proposal for JavaScript.
I do not mind to have better precision for timestamps. Minutes are too
coarse. However I would consider with low priority.
I would prefer to postpone some discussions now
Jean Louis writes:
> * Sterling Hooten [2023-01-27 09:06]:
>> Offset
>> Constant duration difference between times of two time scales
>> (ISO). i.e., a quantity to combine with a time scale to produce
>> a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
>>
Ihor Radchenko writes:
> First of all, thanks for the detailed suggestion!
> I will need more time to look through the provided links and think about
> the ideas.
>
> I will provide one important consideration you missed in the below comment.
>
> Sterling Hooten writes:
>
>> What format and synt
* Sterling Hooten [2023-01-27 15:50]:
> This isn’t (much) of a problem from a display format perspective
> because we can parse the encoded format and present the user with a
> human readable version.
Org files shall still be readable as plain text IMHO.
As Org textual structure has been adopted
* Sterling Hooten [2023-01-27 09:06]:
> Offset
> Constant duration difference between times of two time scales
> (ISO). i.e., a quantity to combine with a time scale to produce
> a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
> scale.
I would be c
Sterling Hooten writes:
>> Design for human consumption is one of the reasons we do provide the
>> redundant information like week day (I personally did find it extremely
>> useful on multiple occasions) and do use spaces, deviating from ISO. The
>> above ISO example is barely readable by humans.
Thanks for the quick feedback!
> On 2023-01-27, at 08:09, Ihor Radchenko wrote:
>
> Following ISO and other standards is indeed a reasonable idea. However,
> the standards are not necessarily designed for human consumption.
> In contrast, Org mode is designed to be read by humans as well, even
>
First of all, thanks for the detailed suggestion!
I will need more time to look through the provided links and think about
the ideas.
I will provide one important consideration you missed in the below comment.
Sterling Hooten writes:
> What format and syntax should Org use?
>
> A heretical sugg
Oh wow... this is a great idea. Good idea sending it round. Ought to make
things a bit easier when discussing and avoiding misunderstandings. =]
On Fri, Jan 27, 2023 at 1:06 PM Sterling Hooten wrote:
> Hi all,
>
> Collaborating around the subject of "time" is difficult; there are
> subtleties a
Hi all,
Collaborating around the subject of "time" is difficult; there are
subtleties abound in implementation, the perspectives people come from,
and the language used in discussions. I'm going to provide a glossary to
establish common terminology, use these terms to analyze our current
state, of
Aloha Max,
Max Nikulin writes:
On 21/01/2023 22:55, Thomas S. Dye wrote:
Aloha Max,
Max Nikulin writes:
On 21/01/2023 07:37, Thomas S. Dye wrote:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not
include UTC
or a
time zone; and 3)
On 22/01/2023 19:14, Max Nikulin wrote:
- ad-hoc timezone that follows user in their trips (close to Ramsey's
"occurrence").
Sorry, it should be "event", not "occurrence". It was not intentional
demonstration of my confusion.
On 21/01/2023 22:55, Thomas S. Dye wrote:
Aloha Max,
Max Nikulin writes:
On 21/01/2023 07:37, Thomas S. Dye wrote:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include UTC
or a
time zone; and 3)
Event not relative to user, where t
Max Nikulin writes:
>> Diary sexps are using this function frequently.
>> In fact, Org also does use this function frequently.
>
> I have not look into this package yet, so I can not comment it.
>
> Should we summon Paul Eggert?
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#10
> Re: bug#5
Max Nikulin writes:
> On 21/01/2023 06:38, Tim Cross wrote:
>> - Use UTC for meetings which are not face-to-face and which involve
>>people form different time zones.
>
> I agree with you that it should considered as first option by whose who are
> planning an
> event. They still may prefer
Aloha Jean Louis,
Jean Louis writes:
* Thomas S. Dye [2023-01-19 19:23]:
Only occurrences require absolute time, UTC. Events do not.
They follow
the user's space/time.
> > > Org in this state can't handle such things.
> >
> > Org can do the useful thing: translate the UTC timestamp
> >
Aloha Jean Louis,
Jean Louis writes:
* Thomas S. Dye [2023-01-19 19:23]:
Only occurrences require absolute time, UTC. Events do not.
They
follow the user's space/time.
I understand you got your context specific terminology, from the
mentioned book, where you are making philosophically di
Aloha Max,
Max Nikulin writes:
On 21/01/2023 07:37, Thomas S. Dye wrote:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not
include UTC or a
time zone; and 3)
Event not relative to user, where the timestamp includes the
relevant time
z
* Thomas S. Dye [2023-01-19 19:23]:
> Only occurrences require absolute time, UTC. Events do not. They follow
> the user's space/time.
>
> > > > Org in this state can't handle such things.
> > >
> > > Org can do the useful thing: translate the UTC timestamp into local
> > > time and
> > > repo
* Alexander Adolf [2023-01-19 20:59]:
> Or to any other timezone. The key point here is that you _do_ specify a
> timezone. Then, everybody can convert that and have it displayed in any
> timezone they find useful.
Concise and very right, thanks!
--
Jean
Take action in Free Software Foundatio
* Thomas S. Dye [2023-01-19 19:23]:
> Only occurrences require absolute time, UTC. Events do not. They
> follow the user's space/time.
I understand you got your context specific terminology, from the
mentioned book, where you are making philosophically different
distinction between occurence an
Jean Louis writes:
> * Ihor Radchenko [2023-01-20 14:50]:
>> Of course, more generally, there is also a question of things like
>> calendar displaying time in different time zone (for example, when
>> choosing timestamp date and time in `org-read-date').
>
> Also consider that calendar has these
* Ihor Radchenko [2023-01-20 14:50]:
> Of course, more generally, there is also a question of things like
> calendar displaying time in different time zone (for example, when
> choosing timestamp date and time in `org-read-date').
Also consider that calendar has these options
(setq calendar-loca
On 21/01/2023 16:21, Ihor Radchenko wrote:
I looked into this further and I note that
`calendar-absolute-from-gregorian' does not account for time zones at
all:
((> year 0)
(setq offset-years (1- year))
(+ (calendar-day-number date) ; days this year
"Fraga, Eric" writes:
> However, having said this, I don't think it's org's responsibility to
> address the Emacs Diary: that would be a feature request for Emacs more
> generally...
I looked into this further and I note that
`calendar-absolute-from-gregorian' does not account for time zones at
On 21/01/2023 06:38, Tim Cross wrote:
- Use UTC for meetings which are not face-to-face and which involve
people form different time zones.
I agree with you that it should considered as first option by whose who
are planning an event. They still may prefer to choose timezone of
particular
On 21/01/2023 07:37, Thomas S. Dye wrote:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include UTC
or a time zone; and 3)
Event not relative to user, where the timestamp includes the relevant
time zone.
For a while I prefer to concen
Aloha Tim,
Tim Cross writes:
"Thomas S. Dye" writes:
Aloha Max,
Max Nikulin writes:
On 20/01/2023 23:09, Thomas S. Dye wrote:
Max Nikulin writes:
Now, if Amsterdam's timezone arbitrarily changes its relation
to UTC before the
conference takes place,
then everyone who participates in
"Thomas S. Dye" writes:
> Aloha Max,
>
> Max Nikulin writes:
>
>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>> Max Nikulin writes:
>>> Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before
>>> the
>>> conference takes place,
>>> then everyone who participates in the confe
Max Nikulin writes:
> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to distinguish the
>> case where the times need to be adjusted and local tz when they don't
>> won't work a a mechanism that can be used to allow org to handle things
>> better than i
Max Nikulin writes:
> On 20/01/2023 15:11, Tim Cross wrote:
>> Max Nikulin writes:
>>
>>> Tim, I am trying to say that any meeting either face to face or on-line may
>>> be associated
>>> with arbitrary primary timezone.
>> and what you are saying is helpful how? In what way does what you are
>
Daryl Manning writes:
> Perhaps a leading question (leading to outrage =p ), but does anybody even
> use those anymore?
>
> I don't believe I've used them at all in 5 years of using org-mode (and if I
> did it was most likely because of
> some arcane older feature which required them).
>
> Da
Aloha Max,
Max Nikulin writes:
On 20/01/2023 23:09, Thomas S. Dye wrote:
Max Nikulin writes:
Now, if Amsterdam's timezone
arbitrarily changes its relation to UTC before the conference
takes place,
then everyone who participates in the conference must notice
this (or miss the
start of the
On 20/01/2023 23:09, Thomas S. Dye wrote:
Max Nikulin writes:
Now, if Amsterdam's timezone
arbitrarily changes its relation to UTC before the conference takes
place, then everyone who participates in the conference must notice this
(or miss the start of the conference).
My point is that if
Aloha Max,
Max Nikulin writes:
On 20/01/2023 15:17, Tim Cross wrote:
So far, nobody has shown any reason why using UTC to
distinguish the
case where the times need to be adjusted and local tz when they
don't
won't work a a mechanism that can be used to allow org to
handle things
better th
On 18/01/2023 23:20, Jean Louis wrote:
Is there any program, software, system, that is really so good with
time, apart from PostgreSQL database that I know with 1195 defined
time zones?
...
name | abbrev | utc_offset | is_dst
-
On 20/01/2023 15:11, Tim Cross wrote:
Max Nikulin writes:
Tim, I am trying to say that any meeting either face to face or on-line may be
associated
with arbitrary primary timezone.
and what you are saying is helpful how? In what way does what you are
sayhing help address my use case?
Tim,
I just usually put those in the cal manually, with a date if they have
"unusual" recurrences that can;t be denoted by the standard datestamp
recurrences . =]
Though for religious holidays like Easter and, I imagine, some lunar based
ones, I imagine it might be handy. But honestly, I am surprised p
Ihor Radchenko writes:
> [...]
> I don't imply that. What I am saying is that we first need to decide on
> syntax and provide basic support for time zones. It will already be
> helpful as I won't need to convert timestamps into local time or think
> if I need to convert timestamps ahead of time b
"Fraga, Eric" writes:
> However, having said this, I don't think it's org's responsibility to
> address the Emacs Diary: that would be a feature request for Emacs more
> generally...
Well. Diary sexps do not support time. So, we may already need to add
time info to diary sexps (at least, it is p
On Friday, 20 Jan 2023 at 18:29, Daryl Manning wrote:
> Perhaps a leading question (leading to outrage =p ), but does anybody
> even use those anymore?
Yes. I use them for repeating events, in particular those which have
repeating rules like "the first Monday of every month" that org does not
sup
Daryl Manning writes:
> Perhaps a leading question (leading to outrage =p ), but does anybody even
> use those anymore?
>
> I don't believe I've used them at all in 5 years of using org-mode (and if
> I did it was most likely because of some arcane older feature which
> required them).
diary exp
Perhaps a leading question (leading to outrage =p ), but does anybody even
use those anymore?
I don't believe I've used them at all in 5 years of using org-mode (and if
I did it was most likely because of some arcane older feature which
required them).
Daryl.
On Fri, Jan 20, 2023 at 5:57 PM Ihor
Ihor Radchenko writes:
> <2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are
> often ambiguous)
> <2023-01-14 Sat 18:22+0800>
> <2023-01-14 Sat 18:22+08>
> <2023-01-14 Sat 18:22@+0800>
> <2023-01-14 Sat 18:22@+08>
One thing we all missed in the discussion is diary sexps.
Tim Cross writes:
> OK, I just give up.
>
> I don't understand why my very simple point seems so hard for anyone to
> grasp and why everyone seems so focused on the booking and scheduling of
> meetings with outhers. This was never in the scope of the very simple
> issue I want solved.
FYI, I fe
On Friday, 20 Jan 2023 at 16:39, Tim Cross wrote:
> My simple sugestion wa that have the commands which insert timestamps
> use the universal argument -when called with the universal argument,
> set the timestamp using UTC and when it isn't, set it as it is now (or
> set it with the local TZ added,
"Thomas S. Dye" writes:
> Aloha Max,
>
> Max Nikulin writes:
>
>> On 20/01/2023 03:09, Tim Cross wrote:
>>> To reiterate for the last time, there are 2 clear and different use
>>> cases for timestamps associated with meetings.
>>> 1. A meeting timestamp for a meeting where all the participants a
Max Nikulin writes:
> On 20/01/2023 12:39, Tim Cross wrote:
>> No, I disagree with that statement. That is old thinking based when
>> meetings meant face to face meetings. Only meeting which have a specific
>> location can have a time zone and even then, it isn't really the
>> meetings time zone,
On 20/01/2023 12:39, Tim Cross wrote:
No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the
Aloha Max,
Max Nikulin writes:
On 20/01/2023 03:09, Tim Cross wrote:
To reiterate for the last time, there are 2 clear and different
use
cases for timestamps associated with meetings.
1. A meeting timestamp for a meeting where all the participants
are in
the same time zone.
...> 2. A meeti
Aloha Tim,
Tim Cross writes:
"Thomas S. Dye" writes:
Aloha Tim,
Tim Cross writes:
"Thomas S. Dye" writes:
Aloha Tim,
UTC is a time zone - just one where offset is +
UTC is absolute time. It lacks the spatial component that
defines a time zone.
Really? I would have thoug
Max Nikulin writes:
> On 20/01/2023 03:09, Tim Cross wrote:
>> To reiterate for the last time, there are 2 clear and different use
>> cases for timestamps associated with meetings.
>> 1. A meeting timestamp for a meeting where all the participants are in
>> the same time zone.
> ...> 2. A meeting
On 20/01/2023 03:09, Tim Cross wrote:
To reiterate for the last time, there are 2 clear and different use
cases for timestamps associated with meetings.
1. A meeting timestamp for a meeting where all the participants are in
the same time zone.
...> 2. A meeting timestamp for a meeting where all
"Thomas S. Dye" writes:
> Aloha Tim,
>
> Tim Cross writes:
>
>> "Thomas S. Dye" writes:
>>
>>> Aloha Tim,
>>>
UTC is a time zone - just one where offset is +
>>>
>>> UTC is absolute time. It lacks the spatial component that defines a time
>>> zone.
>>>
>>
>> Really? I would have thou
Aloha Tim,
Tim Cross writes:
"Thomas S. Dye" writes:
Aloha Tim,
UTC is a time zone - just one where offset is +
UTC is absolute time. It lacks the spatial component that
defines a time zone.
Really? I would have thought the prime meridian was the spacial
component for UTC? I t
"Thomas S. Dye" writes:
> Aloha Tim,
>
>> UTC is a time zone - just one where offset is +
>
> UTC is absolute time. It lacks the spatial component that defines a time
> zone.
>
Really? I would have thought the prime meridian was the spacial
component for UTC? I thought the full long time z
Aloha Tim,
UTC is a time zone - just one where offset is +
UTC is absolute time. It lacks the spatial component that defines
a time zone.
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Jean Louis writes:
> * Tim Cross [2023-01-19 10:48]:
>> You completely misunderstood the specific issue being discussed. You
>> clearly have not been following this specific point being discussed and
>> your long reply just confuses matters rather than helps.
>>
>> This issue is in dealing with
Tim Cross writes:
> [...]
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?
>
> Thinking more about it, in this situation, you probably just need to
> set the meeting time to UTC and that would work.
> [...]
Robert Horn writes:
> [...]
> Getting the rules and explanation clear is the issue. It's a mistake
> that a great many people make with scheduling meetings. Those two
> behaviors need different encodings because they behave differently.
> [...]
AFAIU, setting "clear rules" for this seems impos
Robert Horn writes:
> [...]
> The issue is clarity of the expected rules for the format. If I
> schedule a meeting for 10:05 DST,
> [...]
In all calendaring software I have used thus far, I don't do that. I can
specify a date and time of day only (but never "DST"). The software then
works out (
Daryl Manning writes:
> [...]
> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that
Ihor Radchenko writes:
> Robert Horn writes:
>
>>> Not really. Countries may change DST at any moment in future. Or decide
>>> to switch calendars (consider countries near the day transition line).
>>>
>>> And "past local time, according to the DST rules in effect at the time"
>>> is also an o
Aloha Jean Louis,
Jean Louis writes:
* Thomas S. Dye [2023-01-19 09:37]:
Meetings are occurrences, which require absolute time, which
has no
timezones. Org should record occurrences with timestamps in
UTC,
possibly translating from the user's local time.
User in Grece needs appointment
* Tim Cross [2023-01-19 10:48]:
> You completely misunderstood the specific issue being discussed. You
> clearly have not been following this specific point being discussed and
> your long reply just confuses matters rather than helps.
>
> This issue is in dealing with the meeting time when the l
* Ihor Radchenko [2023-01-19 13:43]:
> So, we should let the user specify time zone to be used for export.
> Then, when sending an email, you can export the heading to text/html and
> Org will set the target time zone as requested.
Exactly.
Follow the iCalendar export option TIMEZONE. Why did au
* Thomas S. Dye [2023-01-19 09:37]:
> Meetings are occurrences, which require absolute time, which has no
> timezones. Org should record occurrences with timestamps in UTC,
> possibly translating from the user's local time.
User in Grece needs appointment at 9 o'clock, and writes it as:
<2023-01
Jean Louis writes:
> Today I was writing offers where I specified en_US time format, and
> where I send it from EAT time zone, just realizing that people in US
> can't understand how did I send the e-mail ahead of time. My
> mistake. It is better that I represent it in their time, then they
> wil
Tim Cross writes:
> Initially, my thoughts on the 3 above are "I have no clue what the sane
> default is" - all options seem to have equal pros and cons. Guess the
> best we can do is go with the simplest solution and 'suck it and see".
I am leaning towards this approach.
We already do things l
Tim Cross writes:
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?
You need to come to an agreement about when to do the meeting. Be it
your TZ, and other participant's TZ, or some other fixed TZ (including
Jean Louis writes:
> * Tim Cross [2023-01-19 00:31]:
>> The problem is with meeting 2 and the assumption there is a definitive
>> timezone for the meeting.
>>
>> Consider this scenario. I have a meeting with two other people. We are
>> all in different timezone. What is the timezone of the meet
Aloha all,
Jean Louis writes:
* Tim Cross [2023-01-19 00:31]:
The problem is with meeting 2 and the assumption there is a
definitive
timezone for the meeting.
Consider this scenario. I have a meeting with two other people.
We are
all in different timezone. What is the timezone of the mee
* Tim Cross [2023-01-19 00:31]:
> The problem is with meeting 2 and the assumption there is a definitive
> timezone for the meeting.
>
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?
Org in this state can'
Ihor Radchenko writes:
> Jean Louis writes:
>
>> ...
>> Should be part of C library to observe those things.
>
> Sure. My previous proposals are all relying on `encode-time' which uses
> time.h from system libraries and utilizing TZDB that is taking care
> about all this insanity.
>
> We, howeve
Ihor Radchenko writes:
> Tim Cross writes:
>
>>> Does it sound good enough?
>>
>> No, I'm afraid not. How does org distinguish between meeting 1 and
>> meeting 2? IN meeting one, when the timezone transitions in/out of
>> daylight savings, nothing needs to change, but in meeting 2, when this
>>
Just leave it out and let Org be single user, single time zone system.
You can't make the impossible. It is not database for sensitive work.
Let it be text.
If they want to convert to their time zone, let them do the home work.
If they don't want to use Org for timestamps, like me, let them be.
* Ihor Radchenko [2023-01-18 13:01]:
> Max Nikulin writes:
>
> > ... I am unsure concerning Windows, it may have an option of quite
> > similar variant. That is why I am not sure to which degree Org should be
> > liberal in respect to various time zones.
>
> May we just support whatever TZ su
* Max Nikulin [2023-01-17 20:31]:
> On 17/01/2023 02:07, Ihor Radchenko wrote:
> > https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
>
> More links:
> - https://stackoverflow.com/tags/timezone/info
> -
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-a
1 - 100 of 210 matches
Mail list logo
