* Ihor Radchenko [2024-02-04 22:40]:
> What do you think about an idea to modify Org mode front page
> (https://orgmode.org/), adding the most recent blog posts and
> discussions about Org mode?
>
> We might use Org-related records from Sacha's news and/or
> https://planet.emacslife.com/ as a
* Thomas S. Dye [2024-01-02 08:39]:
> Aloha Ihor,
>
> Ihor Radchenko writes:
>
> > @@ -22,6 +22,10 @@ ** Summary
> > It relies on a lightweight plain-text markup language used in files
> > with the =.org= extension.
> > +Org files can be viewed using any text editor. You can read and
> >
* Eduardo Ochs [2023-04-16 01:45]:
> do you have a page in https://gnu.support/ explaining in detail how
> you teach Emacs to beginners? It would be nice to have something like
> that...
I just tell them to do Emacs Tutorial. There is no need for page when
it is built-in.
I tell them, open
* Christopher Dimech [2023-04-15 22:37]:
>
> > Sent: Saturday, April 15, 2023 at 2:16 PM
> > From: "Jean Louis"
> > To: "George Mauer"
> > Cc: emacs-orgmode@gnu.org
> > Subject: Re: A dream?
> >
> > * George Mauer [2023
* George Mauer [2023-04-03 18:17]:
> Emacs is a complex tool that itself can take a semester or more to get
> productive in. I know I myself tried for years to move to it and was only
> able to after learning vim bindings pretty well, and starting to use
> Spacemacs. Forcing students to use
* JD Smith [2023-03-25 05:22]:
> > It is more visible, but I am trying to understand what o you consider
> > better then outline-minor-mode
>
> It sets up headline regexps automatically and consistently, and adds
> configurable styling and org-inspired speed keys on headings. At
> core it is
* JD Smith [2023-03-10 07:03]:
> One speed key I added to outli I really miss in org, so I added it:
>
> (if-let ((pos (cl-position '("Outline Visibility") org-speed-commands :test
> #'equal)))
> (cl-pushnew '("h" . outline-hide-sublevels) (nthcdr (1+ pos)
> org-speed-commands)))
>
>
* Ihor Radchenko [2023-03-08 16:29]:
> > The UTC offset is property of the time zone. The future time zone
> > definition will know what is it's UTC offset.
>
> UTC offset is indeed a property of the time zone.
> However, UTC offset may be a subject of change in some time zones.
Yes, and that
* Sébastien Gendre [2023-02-24 15:58]:
> For each lessons, I need to note:
> - Name
> - Schedule
> - Classroom
> - Teacher name and e-mail
> - Assistant name and e-mail
> - URL to the web page of this lesson on our online learning website
> - List of all distributed documents
> - Note on each of
* Cletip Cletip [2023-02-21 19:20]:
> I am not thinking in advance about "queryable" information. I am
> > thinking of structure, or types, and do not worry of future. All
> > types, columns, anything is automatically capable to be queried.
Solely the above paragraph is not giving me enough
* Ihor Radchenko [2023-02-17 16:32]:
> Bruno BEAUFILS writes:
>
> > On Fri, Feb 17, 2023 at 10:55:34AM +, Ihor Radchenko wrote:
> >> > How so?
> >>
> >> latexmk -interaction=nonstopmode
> >
> > Still do not get the problem. I though that the exit code of the
> > underlying process was used
* Clément Payard [2023-02-16 13:16]:
> First of all, thank you for your answer.
>
> Sorry, I am not a researcher :(. I'm just a modest student with a passion
> for emacs, org-mode and PKM environment. So I'm not a big thing ^^. But I
> think I have a working brain and good ideas... so here I
* Ihor Radchenko [2023-02-15 23:38]:
> Bruno BEAUFILS writes:
>
> > When using the org-latex-export-to-pdf on any foo.org file I get the
> > foo.pdf file produced the right way but I also get the foo.tex file.
> >
> > I think that the whole point of exporting to pdf is only to get the pdf
> >
* Bruno BEAUFILS [2023-02-15 21:52]:
> When using the org-latex-export-to-pdf on any foo.org file I get the
> foo.pdf file produced the right way but I also get the foo.tex file.
>
> I think that the whole point of exporting to pdf is only to get the pdf
> file, avoiding the need to keep the
* Ihor Radchenko [2023-02-15 18:17]:
> Jean Louis writes:
>
> > That is not same case as Ihor, when he designated it as
> >
> > 2030-02-09 12:00 -0800 @UTC
> > because there are no offsets @UTC time zone.
>
> I do not recall providing such example. May you
* Thomas S. Dye [2023-02-14 19:50]:
> > What Ihor proposed is time stamp like:
> >
> > 2023-02-14 Tue 12:00:00 +0800 @UTC
> >
> > Though I just say when we put "UTC" that means normally "UTC time
> > zone" and such has no prefix that is positive or negative, can be
> > zero.
>
> Sigh. UTC is
* Max Nikulin [2023-02-14 14:45]:
> On 14/02/2023 16:45, to...@tuxteam.de wrote:
> > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote:
> > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > > > Then just representation must be c
* Heinz Tuechler [2023-02-14 12:44]:
> Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > * to...@tuxteam.de [2023-02-12 16:50]:
> > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > > > * Ihor Radchenko [2023-02-10 13:48]
* Ihor Radchenko [2023-02-13 17:50]:
> Gustaf Waldemarson writes:
>
> > Does something like that already exist in org-mode? Alternatively,
> > what is the recommended and most portable approach to placing images
> > side-by-side?
>
> No, AFAIK.
Org is already a text structure that has
n-type
hyperscope-by-set (C-c h E)
Sets have their names, that is like subtree heading, easier to find
those who are true heading of subtrees, not all are.
hyperscope-by-subtype (C-c h B)
hyperscope-by-temporary-document
* to...@tuxteam.de [2023-02-12 16:50]:
> On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > * Ihor Radchenko [2023-02-10 13:48]:
> > > Jean Louis writes:
> > >
> > > > If you start adding in Org "fixed" time with UT
* Max Nikulin [2023-02-11 07:47]:
> On 10/02/2023 10:29, Jean Louis wrote:
> > 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
> > UTC"
>
> I do not see any reason why obviously invalid timestamp draws so much
> attention.
>
> Re
* Ihor Radchenko [2023-02-10 13:48]:
> Jean Louis writes:
>
> > If you start adding in Org "fixed" time with UTC offset, that is a new
> > type of timestamp, as it is not common in world.
>
> It is how ISO8601 defines offsets.
- did you say you wish to
* Robert Nikander [2023-02-10 06:36]:
> Does anyone else think it might be nice to allow emojis in tags? I
> used to use OmniFocus before I got into org-mode. I had some tags
> that were certain symbols that had meaning to me.
While I do not use it in tags, I use Emojis in headings.
And that
* Ihor Radchenko [2023-02-08 13:36]:
> > Is it Org as program?
> >
> > Or is it human?
>
> Both.
>
> The idea is to ensure exact point of time relative to UTC.
> For example, when you want to schedule something exactly 10024 hours in
> future, regardless of time zone changes.
I got it, thank
* ypuntot [2023-02-05 16:03]:
> For the Poll, the Jeans proposal would be to introduce manually:
> [2024-02-04 12:00 @America/Vancouver]
I never recommend or recommended to anybody, ever, to make timestamps
manually. That is for computer to make it right.
For human, that is to use calendar.
* Max Nikulin [2023-02-05 20:06]:
> On 05/02/2023 01:59, ypuntot wrote:
> > Then, given the time zone and the local time, you can know UTC.
> > If orgmode gets the UTC there is not ambiguity.
>
> Mapping from local time to UTC may be ambiguous, so mapping from local time
> to time zone offset
* Ihor Radchenko [2023-02-06 17:11]:
> Jean Louis writes:
>
> > * Ihor Radchenko [2023-02-05 13:45]:
> >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
> >
> > What does that mean practically? Provide example for better
> > understa
* Marcin Borkowski [2023-02-06 18:34]:
> Out of curiosity: in what time zone you were when you sent this???
In EAT, by heart in Berlin, Europe, at time in future during
DST, as to test various features.
Forgot to change time back by using NTP.
And e-mail went, discovering few problems in the
* Greg Minshall [2023-02-05 21:43]:
> so, i wouldn't blame mail services for accepting mail with odd dates.
> but, i would question MUAs (like mh-e, mutt, etc., i guess) that allow
> one to send e-mail with odd dates. (i mean, i guess if the person
> stands on their head and swears up and down
* Ihor Radchenko [2023-02-05 13:45]:
> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
What does that mean practically? Provide example for better
understanding.
- The UTC offset is not certain to remain fixed in the future.
- If you do not have the time of creation of the
* Ypo [2023-02-05 00:41]:
> I have been thinking about how I would use this feature. So use cases
> appeared, which arose some doubts about how to use this feature, and an
> opinion for the Poll surged:
>
> If I wanted to assist to a "Mastering Emacs book club" meeting in
> America/Vancouver,
* ypuntot [2023-02-04 22:01]:
> Great link!
> https://spin.atomicobject.com/2016/07/06/time-zones-offsets/
>
> "Given a local time and an offset, you can know UTC time, but you do
> not know which time zone you’re in (because multiple timezones have
> the same offset)."
Exactly.
> So, given a
* Ihor Radchenko [2023-02-04 13:58]:
> I used "UTC+2" because it is how offsets are often represented.
> For example, https://time.is/London is displaying the following:
>
> Time in London, United Kingdom now
> ...
> Time zone
> - Currently Greenwich Mean Time (GMT), UTC +0
>
* Stefan Nobis [2023-02-03 18:50]:
> Jean Louis writes:
>
> > Specifying time zone is not ambiguous as long as you use the TZ
> > database for specifications!
>
> That's wrong and you know it.
What I know is based on research and good references. It seems you did
not f
* Ihor Radchenko [2023-02-01 14:12]:
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.
For reason to make it unambiguous, people (representatives of
countries in international associations) are creating the TZ database,
and
* Ihor Radchenko [2023-02-03 14:13]:
> Hi,
>
> We currently have a message in future on top of
> https://list.orgmode.org/
>
> The message is
> https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw, and
> it does not contain the future dates in headers. Just in the body.
>
> Are
* Ihor Radchenko [2023-02-02 11:38]:
> Jean Louis writes:
>
> > * Ihor Radchenko [2023-02-01 15:23]:
> >> [2022-11-12 14:00 @UTC+2]
> >> [2022-11-12 14:00 @UTC-2:30]
> >>
> >> are also fine within the proposed format.
> >
> > The a
* Stefan Nobis [2023-02-01 12:13]:
> writes:
>
> > 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> > it /is/ ambiguous.
>
> As far as I understand the definitions, the point in time "2023-03-23
> 02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.
>
>
* Ihor Radchenko [2023-02-01 13:30]:
> Tim Cross writes:
>
> > The real question is, can the additional complexity associated with
> > including both a time zone name and an offset be justified in order to
> > handle the very small number of time stamps which will fall within the
> > daylight
* Ihor Radchenko [2023-02-01 15:23]:
> [2022-11-12 14:00 @UTC+2]
> [2022-11-12 14:00 @UTC-2:30]
>
> are also fine within the proposed format.
The above format is unclear to me. I look at timestamps every day, too
many, often change them.
I cannot understand what you mean.
If there is
* to...@tuxteam.de [2023-02-01 12:22]:
> ...which stems from the fact that the very concept of "time zone"
> is somewhat ambiguous, too.
For human who reads it without calculating anything, yes.
For computer which is supposed to be programmed by using the time zone
database, no.
> Some time
* Ihor Radchenko [2023-02-01 15:42]:
> Indeed. Org is used by a variety of users with different needs. What I
> just demonstrated is that specifying the time zone is not always
> necessary in timestamps.
Specifying time zone in time stamps is not necessary!
But using the time zone is necessary
* Tim Cross [2023-02-01 12:53]:
> > Let me try to explain better. Just specifying time zone is ambiguous
> > once per year during daylight transition.
> >
> > [2023-03-29 02:30 @Europe/Berlin] is special.
> >
> > According to https://www.timeanddate.com/time/zone/germany/berlin,
> > 2023-03-29 is
* Tim Cross [2023-02-01 11:10]:
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to
> two different time zone definitions (standard v daylight savings).
Of course, without the time stamp, the time zone alone
* to...@tuxteam.de [2023-02-01 10:20]:
> Either I understand you wrong, or you don't know what you are
> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
> points in time, thus it /is/ ambiguous. If you use disambiguating
> "time zones" (MEZ vs MESZ in this case) you can resolve
* Thomas S. Dye [2023-02-01 10:05]:
> Aloha Jean Louis,
>
> Jean Louis writes:
>
> > * Ihor Radchenko [2023-01-31 16:46]:
> > > Specifying just @Europe/Berlin is ambiguous around the daylight
> > > savings
> > > transition.
> >
> >
* Ihor Radchenko [2023-01-31 16:46]:
> Specifying just @Europe/Berlin is ambiguous around the daylight savings
> transition.
Sorry, I cannot see practical example why is it ambiguous. Unless
programmer does not take all information in account, it is not
ambigous. People on this planet agree on
* Ihor Radchenko [2023-01-31 16:46]:
> >>For time ranges, we will only allow a single offset and time zone
> >>specifier for both start and end times:
> >>[2022-11-12 8:00-9:00+08]
> >>If different time zones are necessary to specify the start/end times,
> >>users can still
* Ihor Radchenko [2023-01-31 14:48]:
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans.
Very right, thank you.
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
* 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 wor
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.
Ye
* 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
* 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
* 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
> ---
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
* 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
> ---
* Gregor Zattler [2023-01-28 17:09]:
> Yes, because what they are measuring is "email opens" via
> web pixels and such tracking technologies. That's might be
> a reason why Thunderbird does not show up there.
>
> So while this data somehow shows the sad state of affairs,
> it is not relevant to
* Max Nikulin [2023-01-27 18:22]:
> I was unsure if goto-mode is a typo or some 3rd party package. Have
> you written that you are aware which way it is implemented?
I am aware of inconsistencies, and I wish Emacs would have it
centralized.
> List of recognized protocols is not a user option,
* 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 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
* 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
* Max Nikulin [2023-01-26 19:21]:
> On 25/01/2023 00:49, Jean Louis wrote:
> > When goto-mode works with mid: by me setting up browse-url-handlers,
> > then I have expected Org to work as well.
>
> Do you mean `goto-address-mode'? Have you had a look into its
> impleme
* Ihor Radchenko [2023-01-25 21:01]:
> Jean Louis writes:
>
> > Haven thanks Firefox developers did not complain on users setting
> > their own content types. Firefox can open Org content type and launch
> > Emacs on it, but Emacs "can't" as it is se
* AW [2023-01-26 13:00]:
> This is about a maildirs of kmail on my local machine. The E-Mails are being
> indexed by akonadi on the side of kde-pim. But referring to a certain E-Mail
> from orgmode with a kind of link fails, because I'd need to got to the
> maildir
> and search for the
* Ihor Radchenko [2023-01-25 21:15]:
> So, the suggested links are:
> 1. pdf + page
> 2. video/audio + timestamp
> 3. epub/djvu/mibi + page
>
> Note that all these are basically file: links. While we can make users
> say pdf:... or video:..., or would be more convenient to extend file:
> link
* Ihor Radchenko [2023-01-25 21:15]:
> Jean Louis writes:
>
> >> Suggestions welcome
> >
> > Main suggestion would be to make interface for users to easy setup
> > those hyperlinks.
> >
> > If user is supposed to adapt mind to programmer by setting t
* Max Nikulin [2023-01-25 18:33]:
> I had in mind another person:
>
> Re: URLs with brackets not recognised. Wed, 12 May 2021 22:06:50 +0200.
> > I disagree. URLs are well-specified. Per RFC 3986, the characters
> > allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
> >
* Ihor Radchenko [2023-01-25 15:56]:
> What we can do is add some more known link types. Some of them will use
> `browse-url' as :follow link parameter.
>
> However, what are the link types which are worth including into the Org
> code? I am looking into the protocols supported by Firefox now.
>
* Richard Stallman [2023-01-25 07:32]:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > Would someone please tell me
* AW [2023-01-25 14:48]:
> Has this been done? I'm struggeling (again), how to link to a certain page of
> a PDF, being opened in okular.
>
> ./link/xyz.pdf::123 does not open the pdf at p. 123
Simply do elisp: links with the below function:
[[elisp:(rcd-okular "/home/user/my-file" 2 "small
* 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
* Ihor Radchenko [2023-01-24 14:19]:
> mid: if a known standard, as Max pointed in the earlier message:
>
> RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
> https://tools.ietf.org/html/rfc2392
It is "proposed standard" and far from any ordinary use.
> It makes more sense
* Ihor Radchenko [2023-01-24 12:41]:
> > This is weird since ever. I've been talking to some collegues and everybody
> > has his/her own special approach. Mostly producing a PDF from the E-Mail
> > and
> > saving this and its attachments somewhere. That's a thing that bothered me
> > for
> >
* Max Nikulin [2023-01-24 20:25]:
> On 24/01/2023 01:37, Jean Louis wrote:
> >
> > All URLs defined by Emacs that are to be run by browse-url in Org
> > shall be allowed by org, to let the Emacs settings pass through.
> >
> > And not to hard code it in Org.
>
* Bruno Barbier [2023-01-24 20:31]:
> > [[elisp:(my-handler "I am ok here")][my handler]]
>
> Org also allows the user to define his own link types:
>
> (info "(org) Adding Hyperlink Types")
I understand.
You see, Org is part of Emacs, me I expect that when I follow Emacs
Instructions that
* Max Nikulin [2023-01-24 18:52]:
> > I am mostly concerned that channelling mid: links to browse-url will not
> > work (open empty page in browser) in most cases. This is more confusing
> > than not having mid: link handler at all.
>
> For me it may be a reason to not enable to enable "mid:"
* Ihor Radchenko [2023-01-24 12:43]:
> Max Nikulin writes:
>
> > On 23/01/2023 17:40, Ihor Radchenko wrote:
> >> I am not even sure if we need to make Org open mid: links via
> >> `browse-url'. Maybe it should be something else? IDK.
> >
> > Do you know an alternative? Org already uses this
* Max Nikulin [2023-01-23 14:49]:
> I agree that linking mail messages and Org notes is important. On the other
> hand my impression is that the "mid:" URI protocol is not adopted wide
> enough by mail user agents yet, so it is too early to enable it by default
> in Org.
All URLs defined by
* AW [2023-01-23 16:58]:
> Am Montag, 23. Januar 2023, 11:40:24 CET schrieb Ihor Radchenko:
> > AW writes:
> > >> We could support mid: is the corresponding url schema existed and
> > >> supported by various OSes.
> > >
> > > Isn't this rather important? How many users of orgmode get TODOs via
* AW [2023-01-22 21:49]:
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail
> and need an efficient way to come back from the TODO to its origin?
Absolutely!
There are many uses apart from tasks, there are attachments.
Legally is better not to delete attachment
* Richard Stallman [2023-01-23 07:25]:
> > > Because we already support Orcale, SAP Hana, MSSql and Vertico for
> example.
>
> Would someone please tell me more concretely what kind of "support"
> this is?
You can find interactive support in `sql' library, functions such as:
M-x sql-oracle
* 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
* Ihor Radchenko [2023-01-22 11:34]:
> We could support mid: is the corresponding url schema existed and
> supported by various OSes.
Instead of supporting hard coded `mid:` in Org, you better support
generally anything that users may define with variable
`browse-url-handlers` and
* AW [2023-01-22 00:33]:
> Workflow: E-Mails with a question comes in, I open a TODO heading in
> an orgmode file regarding the question.
>
> Now, I'd like to add a link to the E-Mail under this TODO heading in the
> orgmode file. I've seen the manual page about external links, https://
>
* 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
> > >
* 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
* 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
* 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
* 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
* 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
* 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:
* 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
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
* 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
* 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
> -
>
* Ihor Radchenko [2023-01-18 12:35]:
> > It means there shall be functions which can convert timestamps to the
> > new time zone, with the option to left unchanged those timestamps who
> > already have time zone specified, and with option not to be converted.
>
> I am not sure why you need a
* Ihor Radchenko [2023-01-18 12:29]:
> What should we do when:
>
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>and the users asks to create a timestamp +1h from now
>or, worse, a timestamp +1h from now in a different time zone
I still understand that it
* Ihor Radchenko [2023-01-17 22:51]:
> Some good news is that all the above edge cases would equally affect the
> current Org's timestamp handling code. Yet, we have no bug reports in
> this area. I'd even go further and say that we should not try hard to
> make things 100% accurate: (1) it will
1 - 100 of 573 matches
Mail list logo
