Re: [DISCUSSION] Add "Recent News" to orgmode.org
* 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 source, scrape it regularly (once per > day/week or on every export), and embed the relevant links into the > orgweb/index.html > > This way, visitors can easily see how active Org mode community is and > discover Org-related blogs/forums. Very good idea! -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable
* 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 > > +understand raw Org markup with a naked eye. Although authoring Org > > +files is best-supported inside Emacs. > > + > > As an authoring tool, Org helps you write structured documents and > > provides exporting facilities. Org files can also be used for literate > > programming and reproducible research. As a TODO lists manager, Org > > -- > > 2.42.0 > > How about this, assuming lightweight is equivalent to readable and easy to > understand? > > It relies on a readable and easy to understand plain-text markup language > saved to files with the =.org= extension. Authoring Org files is best > supported by Emacs, but you can view and change them with any text editor. > As an authoring tool ... In my opinion, it's not that Org was intentionally designed to be "lightweight markup readable for humans"; rather, it was maintained in a manner that focused on preserving its readability and prevented it from evolving into something less comprehensible. It's primary use was for Emacs users to make notes, TODO tasks, etc. It is secondary that it became leightweight markup language that can export to various documents. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: A dream?
* 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 Emacs and do the tutorial, then let me know. Later we do not talk much, we just do the work. > Btw, I've taught Emacs to beginners many times, but as "Emacs-the- > Lisp-environment", not as "Emacs-the-editor"... in some cases, like in > LaTeX workshops, lots of students who had never used Emacs before were > happily writing their own one-line elisp hyperlinks and defuns after > just one hour, but in some other cases my approach failed miserably... Answer is simple: (info "(eintr) Top") You could use that as curriculum for the workshop. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: A dream?
* 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-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 emacs, much less org - especially in > > > this day and age where students *will* ask online, and *will* get a > > > response of "no one actually uses that" - will probably meet with a ton of > > > resistance. > > We ran it on the International Space Station. If that is the response of > students, > then they are lame bro, My child of 11 years writes fantasy book using Emacs, and I did not teach him at all how to use it, he just learned it on different computer himself. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: A dream?
* 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 emacs, much less org - especially in > this day and age where students *will* ask online, and *will* get a > response of "no one actually uses that" - will probably meet with a ton of > resistance. We have got no problem to let staff members use Emacs in East Africa. I have not get any protest yet, people are interested. I have seen American surgeon and his brother from university totally delighted with the usage of Emacs and "how everything works in one program". They kept asking what is it. Here is how to verify usability of Emacs, once you verify it, let us know: Usability 101: Introduction to Usability: https://www.nngroup.com/articles/usability-101-introduction-to-usability/ How Many Test Users in a Usability Study?: https://www.nngroup.com/articles/how-many-test-users/ Usability Testing 101: https://www.nngroup.com/articles/usability-testing-101/ -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Mention outli, and h speed-key
* 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 still outline mode. Think of it like org-ified > outshine-light. I have tried this in fundamental mode: >> Ok here Hello there >>> And Ok here Then I was M-x outli-mode and I was thinking headlines will now appear automatically, but nothing appeared there. I don't get it though I find it fancy and nice. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Mention outli, and h speed-key
* 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)))
>
> Basically h=outline-hide-sublevels. This allows you to quickly
> collapse the entire tree to the level [h]ere. It’s a wonderful,
> fast compromise between the ease of Shift-Tab and org’s more
> targeted folding capabilities.
It is more visible, but I am trying to understand what o you consider
better then outline-minor-mode
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 is what I was stating. What we were arguing about is rather notation. > I am referring to "fixed" offsets to be specified by users and will > never change. "Fixed" offset is IMHO wrong designation. What you want to say is "UTC time". Don't use any offsets with UTC time as not to confuse people. Use local time representation of UTC timestamps. For UTC timestamp there is no problem to be in future or in past. > These offsets are convenient to protect timestamp from regulatory > changes in time zones. UTC time is convenient. But if you intend to represent time with time stamps, fixing some "UTC offsets" to get "UTC time" representation, I do not see how it is convenient for anybody. > Effectively, they are simply another, sometimes convenient, way to > represent UTC time. Just use UTC time to tell what "fixed" time, and do not use "UTC offsets" as they are by convention changeable. > Consider that you need to put a timestamp exactly 1 year from now, even > if time zone rules change. You are in +04 time zone at > [2023-03-08 14:00 @Asia/Istanbul]. No matter in which time zone I am, one year from now depends on how year is calculated If current timestamp at UTC time is: 2023-03-10 01:08:07 then one year from now is: 2024-03-10 01:08:07 > You can write [2024-03-08 11:00 @Z] or you can write > [2024-03-08 14:00 @+03]. The latter is nothing but former, written > without a need to mentally convert back to UTC from your current wall > clock. I understand and I do not agree to that notation for reason that it is confusing, but you please do how you wish. UTC offset is shown to user in many applications depending on user's time zone, while time that is fixed is static designation. I would agree to such notation only if UTC time is written in Org file, but you provide representation of UTC time showing the UTC offset. I see now use of providing "UTC time" with "UTC offset" as that is beyond conventions. Then we are speaking out of the reality of what people agreed on this planet, and people agreed not to use any offsets with UTC time. It is either UTC time without offset or offset zero, or no offset at all. But of course Org can be the playground to do what one wish and want. > > You can introduce something new in Org and say "This is fixed UTC > > offset in time zone @ABC" but that way you are confusing yourself and > > future programmer and users, as it does not comply to already accepted > > international standards. > > > > iCalendar proposes different way of representation of time in future,haw > > that is, it could be UTC time in future, or it could be date, time and > > time zone. Using UTC offset for future is redundant, as in present > > time when you are writing future time stamp, you cannot know the > > future UTC offset. > > iCalendar provides just two options: time zone name and UTC. It is ok > when the timestamps are written programmatically, but not ok when the > format should be writable by humans manually. I do not see why we should > force the users to convert to UTC manually in the above scenario. While I cannot see the context of the above statement, I have never had any idea of letting user convert some timestamps manually, that is why computers are there to provide timestamps. I don't do that manually. > >> icalendar is _not_ the only time spec around. We can take it into > >> account, but I do not see any reason to follow it blindly. > > > > How about finding reasons why iCalendar specifies it that way? > > > > And then deciding if those reasons, not specification literally, > > should be followed? > > Feel free to share the underlying logic if you are aware about it. Which indicates you did not do the homework. > >> > 4. Hypothetical example of clear timestamp for future: > >> >[2024-02-04 12:00! @-08,America/Vancouver] > >> >where the time would be stamped with "!" and that would mean that in > >> > the time zone, meeting is at 12 o'clock. > >> >It would assume that UTC offset can change in future, but 12:00 clock > >> > would be authoritative time for future. > >> > >> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver? > > > > The sign "!" is telling "use time, not offset as authoritative". I do > > not say you should implement it this way, but I am saying it is wrong > > putting both the time and offset for future time, while you will not > > know the future offset with certainty. > > Ok. I see the problem you referred to. We should then better stick to > the TEC's proposal here: > > ┌ > │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch > │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 > │ [2022-11-12 1
Re: Org-mode notes about school lessons
* 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 the distributed documents > - Lesson plan > - Notes taken in classroom while the teacher speak > - Notes taken while doing the practice work > - Tasks asked by the teacher Here is the solution with Org: -- * People ** Teachers *** Mr. Evil :PROPERTIES: :ID: 067030f3-b833-4559-8159-6f94913a5408 :E-MAIL: mre...@example.com :END: ** Assistants *** Mini Me :PROPERTIES: :ID: 894a5fe6-f694-44c6-9285-b1fa7727e6c9 :E-MAIL: min...@example.com :END: * Classrooms ** Classroom #1 :PROPERTIES: :ID: 23a3959a-19af-4890-a4de-16aff843f3a8 :END: ** Classroom #2 :PROPERTIES: :ID: 891d563d-96f8-47a5-b7cd-4d4565cf1524 :END: * Lessons ** My lesson name :PROPERTIES: :CLASSROOM: 23a3959a-19af-4890-a4de-16aff843f3a8 :TEACHER: 067030f3-b833-4559-8159-6f94913a5408 :ASSISTANT: 894a5fe6-f694-44c6-9285-b1fa7727e6c9 :URL: https://www.example.com/my-lesson-name :END: *** Distributed documents My document one Notes here about the document one My document two Notes here about the document two *** Lesson Plan *** Notes taken in classroom while the teacher speak *** Notes taken while doing the practice work *** TODO Tasks asked by the teacher --- What I would do for the above referencing system is representation or "jump" function, so that when you have something like this: ** My lesson name :PROPERTIES: :CLASSROOM: 23a3959a-19af-4890-a4de-16aff843f3a8 :TEACHER: 067030f3-b833-4559-8159-6f94913a5408 :ASSISTANT: 894a5fe6-f694-44c6-9285-b1fa7727e6c9 :URL: https://www.example.com/my-lesson-name :END: That I can quickly see which classroom is that or which teacher is that. (defun rcd-org-uuid-name () "Display name for referenced Org UUID." (interactive) (let* ((uuid (thing-at-point 'uuid)) (found (org-id-find uuid)) (heading)) (when (and found uuid) (save-excursion (goto-char (cdr found)) (setq heading (org-get-heading))) (message "%s" heading When you move cursor to one of those UUIDs, you would see "Mini me" in the mini buffer. Or you wish to jump there by UUID: (defun rcd-org-uuid-jump () "Go to heading of the referenced Org UUID." (interactive) (let* ((uuid (thing-at-point 'uuid)) (found (org-id-find uuid)) (heading)) (when (and found uuid) (goto-char (cdr found) The referencing system can enable to make reports on each lesson where names of people and other attributes are nicely displayed. When you change the heading or name of the teacher, the report would get automatically updated. > Thirdly, I need to manage the projects that teachers ask us to do. With > deadlines. > > * What I plan to do > > As I need to write a lot for each lesson, and each lesson are mostly > independent from each other, I plan to have 1 file per lesson. > > In each file, I plan to have the same structure: > - General information > - Tasks and Projects > - Distributed documents > - Notes You need not have one file per lesson, you can write it all in one single file. > In "General information", I put the schedule of the lesson, the > classroom, the teacher and assistant name and e-mail and the URL to our > online platform. > > In "Tasks and Projects", I put all work the teacher ask us to do. For > each, an Org-mode sub-headline with a TODO status. A project is just a task > with sub-tasks. Or maybe have a PROJECT status ? I do not agree to the hierarchy how you specified, as I am used to military style: 1. Plan 2. Programs, belong to plan 3. Projects, they are one step of a plan, when that step cannot easily be executed 4. Orders are tasks, or steps of programs or projects But I cannot see how "Project" is subsection of a "Task", as task is often something very specific. Though in other definitions task can be project too. I just say it is not common, though you can mix terms as you wish. > * What I miss > > There is some point I'm note sure on what or how to do it. > > First, the tasks. I don't know If it's better to keep them in the lesson > org file or move them with all my other tasks (home and work). I think > to include them in the org-agenda, so I can have global view of all ma > tasks. From school, work and home. Yes, and that works. > Second, the weekly schedule. Is it better to have a column view on a > separate file or to see the all the lessons in my org-agenda ? In the > first case, is it possible to build a column view from different file ? > In the second case, how to do it and to manage vacations ? You already got it, how I see it. It is possible to use multiple files fo
Re: Link type in org-mode, but with org-roam ?
* 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 information. It is general statement. In every Emacs buffer anything is automatically capable to be queried. One can search by using regular expressions and there is plethora of other ways to find information. Similarly one can tell that for many other systems. I find almost anything in any text by using `ed' the standard text editor. I am trying to understand what you mean with it, and it that is something that I have not described above. > I was talking about my system which was made with org-roam, so the > information stored in the notes is in plain text. But, to make them > queryable, I have to add "metadata" as said before with key-value. Okay, I understand. Meta data is normally not visible or can be made visible, but is not part of the text, but could be part of Org heading, like Org properties or tags. Including that all words and sentence can also be considered part of it. > So I'm using a database, but I don't want to bother thinking about > how I can add new information to my system. You, you need to think > about "what describes this information?" I cannot see practical example, so I cannot understand. I cannot even know if your description of what I think fits to what I think that I think... hmm, let me see. Do I really think about "What describes this information"? When I enter document in the Dynamic Knowledge Repository, then I name it. In that sense I think of "what describes this information", as I have to describe it, sort it, under some set, which is another way of describing it, maybe relate to people, and so on. However, when you write any text, you are "describing this information". I am trying to understand what you mean and how do you mean of doing things "without describing information". > If it's someone, you create a new table (not sure if this is this > term to use) to hold that knowledge. I don't want to think about > that, I just want to put the information in and find it without > thinking about tables. Yes, database system like GeDaFe is designed for user to create new table. Though that is not happening too often. If you only work with text, you need not special database, as your file system is enough. Org is prime example how text may be structured and mimic database features. > > Because of the design of tables, and conditional correct entries into > > the database, it becomes very easy to find for example "POST BOX" > > address of all people in Mwanza city. > > Here, everything is queryable, because you have already thought of > all the possible cases that could happen. In my system, I decided to > do the opposite: why think of a particular case if I'm not even sure > I'm doing it? It is true that by thinking in advance, one can get better results. For example, one starts creating separate table columns for: - first name - middle names - last name then I realized, people have nick names, what else, so I added another column like: - other names, as array that can hold any number of names then people have their titles, so you add "title" column. But then I realize people have different relationships, may have different roles in different organizations and thus different titles, so I added "people relationship" table, in which "titles" are described individually. And then how to search for that information? PostgreSQL full text search does that. Mastering PostgreSQL Tools: Full-Text Search and Phrase Search - Compose Articles: https://compose.com/articles/mastering-postgresql-tools-full-text-search-and-phrase-search/ So then anything may be queried with simple search, as long as all those fields are updated for full text search: Possible queries could be: - baker in Monaco - Joe, baker - Joe director Monaco and so on, and they could lead to same person. > But our goals are not the same, you have to have a solid system for > several people, I do something much more personal. So, it's ok. I will understand when you show me example. > I wanted to say that adding a new type of information can be time > consuming: you have to add the table, and above all check that > another table does not already exist to do the same thing. That is not time consuming: - adding new table is maybe 1 minute - I never check if other table do the same thing, but I could start making new table to improve previous work Adding tables is rapid on my side. > So you need excellent documentation, hoping that the system itself > doesn't become too "cluttered" for the user. I need documentation, I have little of it. It is just as Org, it needs a lot of documentation for people to use it. > For your purpose, yes. For mine, no. I think that every thing that > has to have a
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
* 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 but after having try to understand some of > > the ox-latel.el I discover that it seems to be done another way > > (analysing the output if I am right). > > Even if we used exit code, what would it achieve? - user wants PDF file - with exit code other but zero there will be no PDF file - display error or move user straight to LaTeX file to try it out manually or find what is wrong. Personally I use exit code from LaTeX processing. - I like to be careful with existing PDF files, as sometimes PDF file is exported in different way, and maybe I am making mistake. So I like to be cautious about it. - Here below `latex-function' must return zero and `pdf-file' must exist for system to update it's Hyperlink correctly, and to launch Evince PDF viewer. - But if error status is not zero, I want to find myself in LaTeX file straight, then I can try C-c C-a to understand why it did not work. (defun hyperscope-latex-to-pdf (id) (let* ((default-directory (hyperscope-expand-directory-for-id id)) (latex-file (hyperscope-hyperdocument-file-name-full id "tex")) (text (hyperscope-text id)) (pdf-file (hyperscope-hyperdocument-file-name-full id "pdf")) (latex-function (lambda () (call-process "pdflatex" nil "*pdflatex*" nil latex-file (string-to-file-force text latex-file) (when (and (file-exists-p pdf-file) (y-or-n-p "Delete existing PDF? ")) (delete-file pdf-file)) (cond ((and (zerop (funcall latex-function)) (file-exists-p pdf-file)) (rcd-db-update-entry "hyobjects" "hyobjects_link" id pdf-file hs-db) (hyperscope-evince pdf-file)) (t (rcd-warning-message "Could not create PDF") (find-file latex-file) If I would just assume that `latex' command "just worked", that means I am blindly continuing with some other functions thereafter, but that would mean I am creating some errors. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link type in org-mode, but with org-roam ?
* 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 am. > The perfect system as I described it does not exist. I've been "looking" > for... 6 or 7 months ? Whatever, I think I'll get to the end of this > search. I was referring to researcher in the definition of what you do, investigating, researching about note taking. Now I realize that the word is used almost exclusively for scientists. > But, before talking about anything, I would like to know several > things: > - I've heard of Hyperscope before your previous message. I mean, I've looked > at some of your posts and (I think) videos... but I still don't understand > where to find it. Can't use it / test it. I think this is on purpose, you > didn't finish it. Yes, I have that problem that database tables are really very dynamic and not well polished to just give them to people. And software is also not polished, it has some hard coding that I have to modify. Yes, I am very slow in providing public package for RCD Notes & Hyperscope for GNU Emacs. But I am very willing to help you install it and try it all out and make it workable on your computer, in one on one chat or by e-mail, that will work well. I strongly suggest reading and understanding this system: GeDaFe - PostgreSQL Generic Database Interface: http://gedafe.github.io/doc/gedafe-sql.en.html As the database is based on that design. Design of program basically says: - design the database table by GeDaFe schema - let system provide functions like add, modify, delete, duplicate automatically > I only found this: > https://hyperscope.link/3/7/1/5/5/RCD-Notes-for-Emacs-37155.html , > which gives a link to get "rcd-cf", which works at my place (after > installing the "emacs-libpq" dependency). I just don't know how to > use it... Is there a tutorial I can do somewhere? Explanations > somewhere? Ehm. I am not Drew Adams to have it all ready since decades. I am working from time to time on documentation and want to make it exteremely easy to install it. One part of it I almost ported to SQLite for people management, but have to polish functions. It just starts working with the Emacs SQLite built-in. So I need to set it up that for user it "just works" for PostgreSQL. > - Second thing, your system seems extremely flexible and adaptable Which is good. It is based on GeDaFe, which means, user is able to add any table, and continue managing information by using same system. > but it also seems terribly rigid. That may be opinion. What is rigid are only relationships, I can say what is rigid: - column timestamp are rigid, they will accept only specific time stamps, and will be automatically generated mostly - referenced columns are rigid, I can relate note only to person which exist in the database. I cannot relate it to person that does not have an entry in the database. If I wish to do so, than I would write it in the text of the entry. But cannot relate it in the database. - column types are rigid, for example ID is integer, I cannot write it as text, UUID must be UUID and must conform to the format, I cannot write integer for UUID. Apart from those rigid principles, nothing else is rigid that I know, at least by feeling, without knowing exactly what you mean. > I don't know what your goal is exactly, but my goal is to make a > system that is easy to use, where the information doesn't have to be > arranged perfectly. Goals are defined in features: RCD Notes & Hyperscope for GNU Emacs, The Dynamic Knowledge Repository: https://gnu.support/gnu-emacs/rcd-notes-for-gnu-emacs/index.html Some of main goals are sales, or helping people, or moving people from one stage to other stage. Imagine some sales flow like: 10, Client has received the offer online 20, Client engages in conversation and resolves all questions and doubts 30, Client arranges the meeting 40, The agreement proposal is sent to client 50, Client may propose modifications to the agreement 60, Client signs up the agreement and pays 70, Service delivered Then person is moved from one stage to other by using communication and documents. Similar "flows" can be applied with patients in a hospital, or orphan child in Tanzania, or development of a school in Uganda. This system overall is used for planning in order to reach goals and purposes. We manage resources, inventory, their locations, geographic locations of resources, maps, people, their locations, their expenditure, reports, plans, programs, projects, tasks, all with purposes of delivering valuable final product. However, system can be used to play B
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
* 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 > > file, avoiding the need to keep the latex one. > > > > I guess that one of org-latex-compile or org-latex-export-to-pdf > > function should remove the source LaTeX file if the compile went well. > > The problem with LaTeX export is that it is not always possible to know > if the process truly finished without errors or not. It is possible to know it always. System commands `latex' or `pdflatex' will emit error status, you may inspect it in shell with: $ echo $? The function `org-latex-compile' does not check for error status, but it could. In general, external processes shall always be checked for exit statuses. It is matter of programming design if you wish or miss to get error statuses and check for them. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
* 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 latex one. > > I guess that one of org-latex-compile or org-latex-export-to-pdf > function should remove the source LaTeX file if the compile went well. Good idea! That will avoid clutter. I can see that problem solved with simple function. One can use different and temporary directory for that file, generate PDF, and once there is no error message by `latex' command, and PDF is there, that PDF can be moved to original directory. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/ signature.asc Description: PGP signature
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 point me to the message > where you saw me writing -0800 @UTC? Discussion on "@UTC" stated with this message by Christian: https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00016.html Theses were examples shown: >Examples: >2022-11-12 12:00+02 # 12:00 UTC+2 >2022-11-12 14:00+0230 # 14:00 UTC+2:30 >2022-11-12 14:00-0230 # 14:00 UTC-2:30 >2022-11-12 14:00Z # 14:00 UTC Those examples are correct but there is comment "#" which was talking about prefixes, only for understanding. Examples without comments are: >2022-11-12 12:00+02 >2022-11-12 14:00+0230 >2022-11-12 14:00-0230 >2022-11-12 14:00Z As you can see there is "Z" as designation for UTC time. When there is designation for UTC time, no prefix is mentined. You may observe that UTC prefixes in those examples are mentioned with positive or negative prefixes, but there is no designation for "UTC", as that would become confusing. Which is what I was speaking about. Where you Ihor responded with this message: https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html > [2022-11-12 14:00 @UTC+2] > [2022-11-12 14:00 @UTC-2:30] > are also fine within the proposed format. I am not sure what did you intend to show, did you intend to tell that: - 2022-11-12 14:00 @UTC+2 means 2022-11-12 12:00 @UTC ? In my understanding "@UTC" means "UTC time zone". From above first examples it is very confusing to use "UTC" as designation plus positive or negative prefix. It is not common to represent it that way. As if there is any designation for UTC, like "UTC" or "@UTC" or "Z", then there is no prefix shown, or if any, there will be zero. And I said, representing time that way by mixing word "UTC" with prefix would be confusing, as that practically creates new type of time representation that is not ordinarily used. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 not a time zone. I cannot know what you mean and in which context. I can tell you to look here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones which is the context for computer time, or TZ database time zones, where you may find Etc/UTC as time zone. I can tell that in the context of the PostgreSQL database, "UTC" is time zone, as following works well: SELECT current_timestamp AT TIME ZONE 'UTC'; timezone 2023-02-16 14:13:37.837977 (1 row) SELECT CURRENT_TIMESTAMP; CURRENT_timestamp --- 2023-02-16 17:13:42.709239+03 There are differen time zones' categories: https://en.wikipedia.org/wiki/Lists_of_time_zones In military context: https://en.wikipedia.org/wiki/List_of_military_time_zones It is called "Zulu Time Zone" or "Z" Then in this context: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations There is abbreviation "UTC" if you look there. So, yes I do agree that UTC is "not time zone", but I do not know in which context you mean. As in many common contexts the UTC is the time zone. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 clear: @UTC is unclear in those > > > > cases, but @RELTOUTC would be clear. > > > > > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all, > > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as > > > said above, it seems not necessary to me. > > > > That's what the "+" and "-" do, anyway. > > TZ=Etc/GMT-8 date '+%F %a %T %z %Z' > 2023-02-14 Tue 19:37:01 +0800 +08 > > TZ=Etc/GMT+8 date '+%F %a %T %z %Z' > 2023-02-14 Tue 03:38:24 -0800 -08 > > Notice sign in time zone identifier is opposite to time offset. However I am > against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is > clear enough. > > P.S. Last +08/-08 are really time zone abbreviations, not offset, however > unlike "BST" & Co. they are acceptable to specify offset > unambiguously. That is different use case Max. For this use case I am in full agreement, that is what is used anyway worldwide. 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. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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]: > > > > > 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 represent time with UTC time zone by using > > > > UTC offset? > > > > > > > > - and I said, UTC time is always without offset, and if any is > > > > represented then it must be +00 > > > > > > > > - and now you say that ISO8601 defines offsets... sorry, you are > > > > confusing me and readers. > > > > > > It is not about "the offset OF UTC". It is about "the offset > > > RELATIVE TO UTC". > > > > Yes, surely is clear to me personally. > > If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is > 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems > intuitively clear to me. I would assume that holds for many others > as well. Exactly that. Never said anything different. Discussion started from something like this: 2022-11-12 12:00+02 @UTC and that is different case, where Ihor was suggesting that: 2022-11-12 12:00 is UTC time, not local time, where by +02 is offset (I say not UTC offset) to be added or deducted on that time. > > That we got for sure. > > > > Then just representation must be clear: @UTC is unclear in those > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all, > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as > said above, it seems not necessary to me. As idea I understand Ihor and other person on Internet. But as implementation by using @UTC or by using date time representation as UTC time with offset (not UTC offset), I think it will be confusing for people, unless there is new tag invented to make sure of it. Any idea is fine: 2022-11-12 12:00+02 @UTC-SUM 2022-11-12 12:00+02 @UTC-TO 2022-11-12 12:00+02 @TO-UTC but not 2022-11-12 12:00+02 @UTC As that would be confusing. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FR] Side-by-side images during export (was: [BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)])
* 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 elementary objects defined,
as you said, not everything is granular, but there is no limit what
users can define in Org.
Elementary Objects:
https://www.dougengelbart.org/content/view/110/460/#2a1a
So anything can be elementary object, no matter in what kind of a
system.
By having that in mind, I think other objects could be used to get
what user wants.
In Asciidoctor I can make table with invisible lines, and position
pictures inside of cells, or place some text on sides. There exists
Asciidoc export for Org. What you read is now my thoughts about it,
development towards possible solution:
| My left | My right |
|-+--|
| left| right|
Giving this with Asciidoc Org export:
[width="80%",options="header"]
|
| My left| My right
| left| right
|
Then this here:
| [[./img/a.jpg]] | [[./img/b.jpg]] |
Get correctly exported as:
[width="80%"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
in Asciidoctor.
One can use that as fundamental point. Instead of using Asciidoctor
export, one could use source blocks to generate LaTeX export by using
Asciidoctor markup.
Here is only the idea:
#+BEGIN_SRC asciidoctor-to-latex
[width="80%"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
#+END_SRC
Then based on following function, one can conevert that above:
(defun rcd-asciidoc-snippet-no-header-footer-to-latex (text)
"Return LaTeX for Asciidoc snippet TEXT without header and footer."
(let* ((text (rcd-asciidoctor text "-s" "-b" "docbook5"))
(text (rcd-pandoc-convert-string text "docbook" "latex")))
text))
(rcd-asciidoc-snippet-no-header-footer-to-latex "
[width=\"80%\"]
|
| image:./img/a.jpg[]| image:./img/b.jpg[]
|
") ➜ "\\begin{longtable}[]{@{}
>{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) *
\\real{0.4000}}
>{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) *
\\real{0.4000}}@{}}
\\toprule\\noalign{}
\\endhead
\\bottomrule\\noalign{}
\\endlastfoot
\\includegraphics{./img/a.jpg} & \\includegraphics{./img/b.jpg}
\\end{longtable}
"
and by using the above think process, it is possible to make
following, by using the Org snippet:
#+BEGIN_SRC org-to-asciidoc-to-latex
| [[./img/a.jpg]] | [[./img/b.jpg]] |
#+END_SRC
then such Org snippet can be converted to Asciidoc, then to docbook5,
then to LaTeX or to HTML.
Solution is right there by using pandoc, asciidoctor and "elementary
objects" as Org Babel source blocks.
And this may not be the only solution.
> There are two problems:
> 1. We currently lack object-granular control over export attributes.
>Attributes for images are set for the whole paragraph and Org uses a
>paragraph starting with image as a special case, assigning paragraph
>to the image.
By using above method, that is solved for each individual user how
they wish and want. It does not need much adaptation IMHO.
> 2. There is no easy universal way to create side-by-side images for all
>possible backends.
As if you do not control those backends, there is also no need for that.
However, by using the above method, it is possible to solve it for all
backends straight from Org, by only adding conversion function.
> The best thing we might provide is merging multiple images into one
> using, for example, a LaTeX minipage export to create merged image
> to be included into the exported document.
Merging multiple images sounds to me as hard coding.
Providing small conversion functions for various exports like HTML,
Org would just make it work.
I did not provide final example in this e-mail, but now you could, I
gave you the thought process and functionality.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: Link type in org-mode, but with org-roam ?
y people lists is useful hyperscope-by-related-contact Any contacts can be related, why not search for it? hyperscope-by-report Object can be task, task is assigned to person Joe, by author Hans, and has to be reported to Jimmy, there is description, text and report, and chunked reports. Searching by report is very important. hyperscope-by-slug (C-c h J) Those things for Internet. I use it more often. Why not search for "scribd.com" when I need it. By the way, I made the scribd.com type of links to be opened by "Scribd Downloadere" if user wants. hyperscope-by-tag (C-c h t) This I use often. hyperscope-by-text That is clear. hyperscope-by-type-and-column For example, you want Music by author, directory by name, or Gnumeric spreadsheet by report. Combinations in searching will help user to get better intersection results. hyperscope-by-type-with-action How about "Task COMPLETED", or "Music PENDING" hyperscope-hyperdocuments-by-action hyperscope-hyperdocuments-by-size hyperscope-hyperdocuments-by-timestamp Timestamps are other sub-objects, each can have description, activity, etc. 10 possible completions: ACTION [5] ACTION-REMOVED [7] CLOCK-IN [3]CLOCK-OUT [4] COMPLETED [6] DEADLINE [2]FOLLOW-UP [11] MEANWHILE [12] RE-ASSIGNED [13]SCHEDULED [1] hyperscope-list-by-contact All objects by contact hyperscope-tags-by-type There are different tag types, one is for industry, other is for skills, is not same all in one. hyperscope-by-argument Arguments I use flexibly as they depend on the type, subtype. Imagine those search engines, like the first one most important one: 78835 The Pirate Bay Web Server Query Default 78669 Duck Duck Go! Web Server Query Default 78675 Reasonator Web Server Query Default 78673 Wikipedia (English)Web Server Query Default 78674 Wikinews (English) Web Server Query Default Then there is argument: https://thepiratebay.org/search.php?q=%s&all=on&search=Pirate+Search&page=0&orderby= which is in this case Emacs Lisp format which will be replaced with the query. In fact when I place that link in Org, when I wish to click on it, I am asked for query, search engine opens automatically on it. But in "Hyperscope ID" type, there will be just integer like 123 pointing to other Hyperdocument. hyperscope-by-author-name Clear. hyperscope-by-country Yes, objects are related to countries, very necessary. hyperscope-by-description (C-c h D) Description is just one part of text properties of object. hyperscope-by-hyperdocument-subtype hyperscope-by-hyperlink-type hyperscope-by-keywords That is for Website Revision System keywords, for HTML pages mostly. hyperscope-by-link (C-c h k) Very often used to find by link. Implement yourself. hyperscope-by-markup-and-column You want maybe Asciidoctor by name, or Org markup by description? hyperscope-by-people-id Searching by ID of people. hyperscope-by-rank Show those most activated documents first. hyperscope-by-relation-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 There are "temporary" documents, like PDF file can have extract of text in that property, and why not search for text from PDF file? It is logical. But temporary document may look ugly. However, searching through PDF files would be more difficult directly. hyperscope-by-type (C-c h T) hyperscope-by-type-and-subtype Combine types and subtypes, that is probably what you need. hyperscope-by-wrsogimage HTML pages on Internet have schema, so those images that appear as preview are there. hyperscope-follow-ups-by-persons-country You are to see list of objects related to people, in different countries. hyperscope-hyperdocuments-by-query-but-not-in-set General search, just exclude the set! hyperscope-hyperdocuments-by-template Objects may use templates for their representations, find those using ABC template. hyperscope-hyperdocuments-pending-by-assignee Too many tasks pending by assignee, so find those pending. I hope that gave you ideas for implementation of new package of Org relationships. > - Some people often have subjects related to this type of question > (I think in particular of a certain "Jean Louis"): have you found > better solutions? I did not read that until I came to it, but thanks. I need relationships between documents. That is a must: - if page is published, and related hyperdocuments are also "publishable" they are shown in export on the HTML page or PDF page, etc. No thinking about it. - if page is duplicated from previous Hyperdocument, that new one automatically become "CHILD", thus related to previous one. It also includes relationships to various other "properties" or "attributes". The more, the better. Doing that in Org directly is overkill. But using UUID and putting relationships on that UUID may be practically implemented within minutes. If user is Org centric, and needs various properties not otherwise implemented in Org, then using UUID can provide such feature easy, and then you can also search between documents. You can for example, update Org heading, and later just have function updating all names of headings to their corresponding UUID in the database. I would stick to only this: * My heading :PROPERTIES: :UUID: 282f7242-a3b1-4bd6-94b6-7283303ae7ed :END: And I was exploring option to make it invisible. That way, user can edit that heading, and because of relationship to database or stored hash database or other type, any kind of properties can be stored. The more various types of properties are there, the easier will be the query in future. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 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 represent time with UTC time zone by using > > UTC offset? > > > > - and I said, UTC time is always without offset, and if any is > > represented then it must be +00 > > > > - and now you say that ISO8601 defines offsets... sorry, you are > > confusing me and readers. > > It is not about "the offset OF UTC". It is about "the offset > RELATIVE TO UTC". Yes, surely is clear to me personally. That we got for sure. Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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. > > Resolution may be rather concise: behavior is *undefined* since field values > are mutually inconsistent. Perhaps implementation may prefer to treat it as > 2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. `org-lint' > should issue a warning requesting a user action. Thank you! I have demonstrated that Etar application from F-Droid would disregard what is invalid and basically only enter valid time. Same for Google calendar, it would disregard invalid timestamp (even though not represented as above), and it would enter only valid one. PostgreSQL will "silently" ignore what does not belong to it. One can search for "silent" here: https://www.postgresql.org/docs/current/datatype-datetime.html > Could you explain what is wrong with the following (without timezone)? > > 2030-02-09 12:00 -0800 > > I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that is a > UTC timestamp. 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. In this different case you wish to say that it is: time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time 2030-02-09 12:00, and one can derive UTC time. That is totally alright as representation of time. That is how past timestamps are represented in local time. Why not -- you can use it for future. I find it less useful for exchange purposes, almost useless, but you can do. Because if you store time as UTC, you can always see local time anywhere in the world. But if programmers wish to do that to Org, okay fine. It is different time type representation, that does not exist in ISO 8601, but why not, you can include it in Org. You just be sure that you put a "tag" or such representation that users will know what is it, even from plain text. > The format with explicit offset may be convenient for a person > living in an area that *likely* will have -08:00 offset and who > would like to watch some astronomical event such as lunar eclipse > and who had a plan to connect to some telescope on the opposite side > of the globe. Event time will not change if local time changed. Both > variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be > presented as "2030-02-09 12:00" to users. And now you speak of presentation. But then why store it with 2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z and have representation be same "2030-02-09 12:00" to users. So that is only addition to programmer. Remember that not even databases store the time like that. It is either UTC time, or date, time, and some time zone stored separately. > If timezone offset is changed both variants will converted to > "13:00" or "11:00" depending on sign of change. Correct. I understand you want to say that representation of time for that UTC time zone will be modified depnding of change, and that is correct. > So the format with offset is human friendly because it gives a hint > concerning *probable* value of local time still remaining *precise* > in respect to UTC. This representation of time is human friendly: 2030-02-09 12:00 -0800 and that is the way how I daily see my timestamps, like this: 2023-02-12 12:59:52.839773+03 which does not differ much from that one. However, my timestamp is only represented with +03 UTC offset. It is not stored with UTC offset. Storing values is not equal to representing values. - In other software values are not stored as "UTC time that has offset" - It is stored as "UTC time" - Offset is calculated from time zone and represented to user. Of course you need not follow what other software does. Though I think you need rather exact designation for users to unmistakably can understand what you mean with it: - Right now when I press C-c . I get: <2023-02-12 Sun> - C-u C-c . and I get <2023-02-12 Sun 13:03> - Then I can think you (developers) will invent something like: <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid invalid time stamps), which is UTC time: 2023-02-12 12:03:00 - Then I can think you would invent time stamp which you proposed, something like: <2023-02-12 12:00 -08:00> which in this case cannot have day representation, as one cannot know which day is that, right? And in this case that timestamp would mean it is 20:00 o'clock UTC time. And which can be replaced with <2023-02-12 20:00 @UTC> I am just not sure if that will be enough human friendly to say: <2023-02-12 12:00
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 represent time with UTC time zone by using UTC offset? - and I said, UTC time is always without offset, and if any is represented then it must be +00 - and now you say that ISO8601 defines offsets... sorry, you are confusing me and readers. Please see here: https://en.wikipedia.org/wiki/ISO_8601 on right side, there is representation of UTC time: Date and time in UTC 2023-02-12T06:45:15+00:00 2023-02-12T06:45:15Z 20230212T064515Z Do you see? There is no offset larger or smaller than zero. We were discussing of a time stamp at @UTC time zone with offset! That type of a timestamp does not exist. What exists with positive or negative offset is timestamp with time zone other but UTC. But not with UTC. If you do introduce positive or negative offsets at UTC time zone, you are introducing something new in Org. It is not necessarily bad, but IMHO you will create more confusion, for no good reason. > > Here is suggestion: > > --- > > > > 1. Convert local time timestamp to UTC > > 2. Add 10024 hours > > 3. Provide timestamp in UTC > > This will involve converting time, which is prone to errors. I still > think that sometimes it is more convenient for human to use familiar > time zone and fix the offset for future. Your answer is not related any more to @UTC time you were mentioning as now you are using "familiar time zone". I said, there is no offset representation with UTC time but +00. But it can be with other time zones. However, when you say "fix the offset for future" that does not work. If you do specify time zone, you are fixing it by time zone, and not by UTC offset, because it is less likely that the time zone definition changes, but UTC offset can change easier. The UTC offset is property of the time zone. The future time zone definition will know what is it's UTC offset. You can introduce something new in Org and say "This is fixed UTC offset in time zone @ABC" but that way you are confusing yourself and future programmer and users, as it does not comply to already accepted international standards. iCalendar proposes different way of representation of time in future,haw that is, it could be UTC time in future, or it could be date, time and time zone. Using UTC offset for future is redundant, as in present time when you are writing future time stamp, you cannot know the future UTC offset. > > Also look at this reference: > > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html > >i > > , > > | The form of date and time with UTC offset MUST NOT be used. For > > | example, the following is not valid for a DATE-TIME value: > > | > > | 19980119T23-0800 ;Invalid time format > > ` > > > As with the above format, author would maybe think it is alright, but > > in general it is confusing. If author wish to specify UTC time, then > > no offset shall be used. > > icalendar is _not_ the only time spec around. We can take it into > account, but I do not see any reason to follow it blindly. How about finding reasons why iCalendar specifies it that way? And then deciding if those reasons, not specification literally, should be followed? > Reading the linked RFC spec, I did note that the motivation for the time > format used in calendar is mainly scheduling meetings for people > residing in different time zones. And I think that is what we are talking about, about conclusive time representation in cases where Org users need it. If meeting or not, that is something for users to decide. Important is only to define the types of time stamps, and then let users use it. Goal is to improve Org timestamps so that Org get feature of conclusive time representation. That means to me, that inconclusive, like floating timestamps can be left how they are, only new are added. For past time representation is best using UTC timestamp, as such can easily be converted to local time. But how? Using overlays? Or updating time stamps in buffer? Or using updated local time timestamps in exports? There is that time stamp for future, if it should not be floating or non-conclusive, then you use date, time and time zone. You insist on "fixing UTC time offset for time zone", but I do not understand that reasoning, as it is contradictory to time zone database use per se. > I can see how the icalendar format is reasonable within that > specific purpose. I cannot see why Org timestamps should be limited > to meetings. "Meeting" is not for Org to specify, that is for user to speci
Re: emojis in tags?
* 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 creates problem in exporting as Org to LaTeX for example, as Org cannot solve the problem. One solution to include Emojis in LaTeX would be to use this package for LaTeX: alecjacobson/coloremoji.sty: Style package for directly including color emojis in latex documents: https://github.com/alecjacobson/coloremoji.sty -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 you. iCalendar allows UTC time. If you have UTC time, you need not have UTC offset, as that is NOT what other programs are doing. My recommendation is follow what is successful. If you wish to use UTC time, use it, but no need to add offset as it will be confusing. Timestamp is either in UTC or in other time zones. UTC time has no offset. 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. Here is suggestion: --- 1. Convert local time timestamp to UTC 2. Add 10024 hours 3. Provide timestamp in UTC Also look at this reference: https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html , | The form of date and time with UTC offset MUST NOT be used. For | example, the following is not valid for a DATE-TIME value: | | 19980119T23-0800 ;Invalid time format ` As with the above format, author would maybe think it is alright, but in general it is confusing. If author wish to specify UTC time, then no offset shall be used. > The same can be done by specifying the timestamp in UTC directly. That is simplest. > > Another program in future, and human, must know did the organizer of > > event, had in mind: > > I would like to remind you that timestamps are not necessarily used for > meetings. And not always shared with other people. Ok, and I have asked you to provide practical examples. Calculation of time shall not be made for sake of sole calculation, but for human and by considering use application. Timestamps for past time, like for logs, I always store as UTC time in database, with time zone (which does not mean that time zone is stored, but displayed in local time zone). However, future time to be coordinated with people, anything human related, it has to be stored with date, time, and time zone in separate fields. That way program in future will understand it. Timestamp is in general always considered past, not future. That is where the word comes from, the "stamp", if you stamp something, it is on paper, when it was done. It is not about "When it will be". https://en.wikipedia.org/wiki/Timestamp A timestamp is a sequence of characters or encoded information identifying when a certain event occurred, usually giving date and time of day, sometimes accurate to a small fraction of a second We have to distinguish in Org what we are doing here, and meaning with "timestamp", as in Org context, timestamp is more than just time when something occured. In Org context there is new type of "timestamp" which is meant for future. Timestamp for past -- should be as accurate as possible in general applications. Practical example of a timestamp: I enter person's contact details, the moment I enter such details, the timestamp is created. It is not 100% accurate to the event that really has taken place, as computer user need some time to write first name, last name of person, it is "about". But for the sole entry of the data in database, that timestamp is pretty accurate. Timestamp for future is not really timestamp, it is intended time, in many applications it cannot be accurate. The last example on the page: https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html gives good clues how to specify date and time in future. > > I find such situations rather easy to solve with database: > > > > - I can have column like "timestamp" with UTC time or local time plus > > UTC offset, and if I did not enter any other information, that UTC > > offset is considered in future. Consider this column name > > "timestamp". > > > > - I can have column "time" and when such is entered, then date is > > extracted from "timestamp" column, and combined with time. In this > > case UTC is only calculated in new time point but not used as period > > from past to appointment time. > > > > - I can have time zone for the future, if I enter such in other > > column, the future calculation must use that proper time zone. > > Sorry, I do not understand what you are trying to explain here. Would > you mind showing an example? The above quote came from explaining that you should not use "time offset" to designate UTC time, as such offset will be mistaken in future for "UTC offset". By doing that you are creating new type of time representation that is not used anywhere else (for future purposes). Example --- 2023-02-01 12:00 -08 @SomeTimeZone would mean that UTC offset at that time and date was -08. One can derive UTC time easily and it will be accurate. 2033-02-01 12:00 -08 @SomeTimeZone, means that one should consider that @SomeTimeZone in future to first derive the UTC offset, as -08 can only be taken va
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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. Calendar must use time zone databases in background as to avoid placing invalid timestamps. > And org to convert it into: > [2024-02-04 12:00 @-08,America/Vancouver] If we speak of future planning, general recommendation I have already referenced is: - to say date, time and time zone, - while knowing one cannot know if time zone will exist in future - while knowing UTC offset may be changed in future, for future timestamps for human meetings is not necessary and not absolutely possible to know UTC offset - future time zone database could tell that time zone does not exist any more. It could maybe try to derive new time zone, but it is vague, as cities and countries could change. - future time zone database can have the new updated UTC offset. - if offset is placed in future timestamps, again the future time zone database should be consulted. Change of UTC offset would not humanely change the time of meeting. If time of meeting is 12 o'clock, then it would remain same, no matter offset. But other participants would need to consult time zone database to understand the time of meeting. - for past timestamps local time plus UTC offset is good choice. p-- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 may be ambiguous as well. Okay, though explain practical case examples. Local time to UTC is almost always used in computing for accurate log purposes. Using UTC time for future events is vague, for reason that other human cannot know with certainty what the author intended to do. Maybe author intended meeting at 10 o'clock, but UTC offset in author's or participant's time zone changed, or even time zone entry is not any more. Author maybe had UTC offset -5, but now is -7, it becomes vague what time author really intended. Local time to time with UTC offset for same reason could be non-conclusive in future. Past is alright, as local time with UTC offset is pretty certain as time zones hardly change in past. Org needs first use examples, and then implementation for use examples. > Usual case is local time change due to daylight saving time. Notice that 2nd > and 4th lines in the results table have the same input, but time offset > differs by 1 hour in the output while local time is the same: Which is good example to demonstrate to people that 2:30 o'clock alone cannot be represented in such time zones without UTC offset. That "02:30" appears twice, it does not mean it is ambigous, as UTC offset or different name of time zone like CET, CEST, would indicat what time is that exacctly. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 > > understanding. > > It means "when I scheduled this item, I expected the UTC offset at the > time of the timestamp to be -08 and remain so. It was motivated by > America/Vancouver time zone, but if it changes in future, I do not care > - the scheduled time should remain at specific time point relative to > UTC". I read, though sorry, I do not understand who is expected to think that UTC offset is fixed? Is it Org as program? Or is it human? Another program in future, and human, must know did the organizer of event, had in mind: - to rather keep appointment at 12:00 o'clock, no matter the UTC offset changes, or - to keep appointment based on UTC definition? I find such situations rather easy to solve with database: - I can have column like "timestamp" with UTC time or local time plus UTC offset, and if I did not enter any other information, that UTC offset is considered in future. Consider this column name "timestamp". - I can have column "time" and when such is entered, then date is extracted from "timestamp" column, and combined with time. In this case UTC is only calculated in new time point but not used as period from past to appointment time. - I can have time zone for the future, if I enter such in other column, the future calculation must use that proper time zone. The above handling is for program to handle and for human to know that it is handled that way. You said "I do not care", that means you as human decide that [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset But from where in such timestamp does user or program understand that? > > - The UTC offset is not certain to remain fixed in the future. > > Yes. But fixing UTC offset means that time point is fixed. Example: you > need a timestamp exactly N hours from now. It must not be affected by > time zone rule changes. Not generally! As I said, your time stamp is not structured, I cannot see how do you decide the appointment here: [2024-02-04 12:00 @-08,America/Vancouver] 1. Both time zone and UTC offset may be changed in future. 2. You as organizer you were maybe meaning UTC time "fixed" with offet -8, but the UTC offset maybe changed in future, it became -07. It is confusing, and neither program neither human will know with certainty if you meant 1 hour more or less. 3. To solve that problem, appointments are better defined as following, with the structured time stamp: * Meeting, discussion of our plan beyond 2030 :PROPERTIES: :TIME: 10:00 :TIMEZONE: Europe/Berlin :END: Or this way, but I do not find that practical, however, "UTC-TIME" could mean to program that it is fixed. * Meeting, discussion of our plan beyond 2030 :PROPERTIES: :UTC-TIME: [2024-02-04 12:00 @-08, America/Vancouver] :END: However, if you do not define UTC-TIME to mean fixed, how is program to know that the timestamp: [2024-02-04 12:00 @-08, America/Vancouver] means that it is -08 UTC fixed offset? Without putting some structure, it will not know it. Maybe this way (hypothetically): [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] as that way you would give signal to program that you want UTC fixed time in future, and not 12:00 o'clock necessary. Without any tag, neither program, nor authors, cannot know which time will it be in future, if there is DST change, time zone change or replacement of it, or UTC offset change. Structuring it, becomes clear DATE:, TIME:, TIME-ZONE: as future TZ database can give information of UTC offset and various local times for TIME: > > - If you do not have the time of creation of the timestamp above, you > > cannot know with certainty what was the offset in past, to calculate > > new UTC offset in case it changed > > America/Vancouver in the above timestamp is nothing but a reference > comment. One may or may not use it. > > > - As not even time zone is certain to remain in existence in future, > > you will need to use time zone, in order to derive that future UTC > > offset correctly. As it could change in mean time. > > If timestamp must follow the future time zone rules, can just use > [2024-02-04 12:00 @America/Vancouver] Exactly. And that is human friendly versus UTC, which is not readable. > >> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time > >> zone, as it is be defined in you OS time zone database. > > > > If you do not keep UTC offset, you will miss changes in future and > > generate errors. >
Re: [POLL] Proposed syntax for timestamps with time zone info
* 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 mailing list software, and Dino messenger. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]
* 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 that they mean to do it, `mutt' is program that receives date from system date. Nothing wrong with it alone. You cannot blame computer program for doing what is instructed. Programs know the time we gave to them. A server for mailing list is much more important program than single MUA. Mailing list solves communication of many people. Such computer is always online and can easily synchronize time with Internet servers. In my opinion central computer that manages mailing lists should recogniz if time of users is far in future and handle it appropriately. Maybe re-writing time with explanation in e-mail header would be more appropriate. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 timestamp above, you cannot know with certainty what was the offset in past, to calculate new UTC offset in case it changed - As not even time zone is certain to remain in existence in future, you will need to use time zone, in order to derive that future UTC offset correctly. As it could change in mean time. What is meaning of "fixed -8 offset"? > [2024-02-04 12:00 @-08] will also use fixed -8 offset That type of timestamp does not clearly show the time zone, that one may only be understood as timestamp with UTC offset. UTC time may be derived from such timestamp. That offset should remain fixed, as there is no time zone associated. It is UTC time represented with offset. > [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time > zone, as it is be defined in you OS time zone database. If you do not keep UTC offset, you will miss changes in future and generate errors. > [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8 > offset, but also calculate America/Vancouver time from TZ database, > compare it with the time coming from -8 offset, and warn you if there is > inconsistency. The UTC offset is the log what was the UTC offset at the time point when timestamp was created, as future UTC offset cannot be known. Making it "fixed" does not fix it in real time, you are then introducing something new than what other programs do with time. I do not think that you need "!", you are creating work not necessary for users. If users wish to get some warnings, let them customize single option. Not timestamp by timestamp. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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, while living in Spain: Doubt: Should I use local time of > America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 > @America/Vancouver] (I don't like space before the @, for the Poll). The above sounds as good idea! People are in Vancouver, so it is 12 o'clock on 4th February, by using time zone "America/Vancouver". If that time zone changes before the future even, the time zone database is going to hold change variables, and one will still be able to figure out the time. > 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00]. > (Spain local time). Correct? Your agenda time stamp could be with Spanish time zone. Your agenda is really this: [2024-02-04 12:00 @America/Vancouver] And that would mean if you wish to represent it in Spanish time zone, that computer program should: - First read the [2024-02-04 12:00 @America/Vancouver] - read time zone database properties for America/Vancouver, this implies having latest time zone databas - apply properties, such as possible UTC offsets, this implies possible changes of UTC offsets - calculate the UTC time, at time point of reading that time - understand local time zone, also calculate UTC time - use above information to calculate Spanish time and representation in Spanish time zone > 2. If I went on vacation to Brasília, my agenda timestamp should change to: > [2024-02-04 do. 17:00]. (Brasília local time). That is okay. > Doubt: How must the local time zone be updated to get that timestamp > changed? By similar formula as explained above. > 3. Back to Spain, I see that, for political reasons, Vancouver's winter > time-zone changed from UTC-8 to UTC-9. > Doubt: How would my tz database be updated? By your system package manager and operating system maintainers. If they do not update it, you would miss the time. If there is any updated beyond international agreement like what is now happening in Ukraine, I doubt you would have correct time calculated by computer. > Doubt: After updating the tz database, my agenda timestamp would change > automatically to [2024-02-04 do. 22:00]. Correct? Org will not know if you did update TZ database or not. That super Org who knows how to calculate times should definitely use the TZ database. Time stamp would not change because you only come to some location. But you also need to change the computer time settings (to be correct time) and computer time zone. If not computer time zone, then the settings for Org, as Org could have in future settings of time zone Once those settings are applied, your Org could show you local time. > 4. For the Poll: What would be the expected behavior if we used the UTC > offset? [2024-02-04 12:00 @-08,America/Vancouver] When time is not too far in future, it is less vague. When time is more far in future, it is more vague, as UTC offset could be changed and time zone name could be changed, but TZ database would have that information to re-calculate it in that future. It means that UTC offset here: [2024-02-04 12:00 @-08,America/Vancouver] is only something that is assumed, it could change, both with fact that time zone could disappear, new time zone could appear. TZ database would be handling those issues, that is the purpose of it. Using UTC offset in future timestamps does not make sense as it is not time that one can calculate in present time with certainty for reason that future TZ database does not exist in present time. Here is good recommendation for such case: Time Zone Storage in Data Type "Timestamp With Time Zone" - ITCodar: https://www.itcodar.com/sql/time-zone-storage-in-data-type-timestamp-with-time-zone.html Booking future appointments where we want to keep the time-of-day even if those pesky politicians change the offset of the time zone(s) in their jurisdiction. These political changes happen surprisingly often. So book an appointment using two columns: TIMESTAMP WITHOUT TIME ZONE in one, and the name of the intended time zone in another. Time zones are named with Continent/Region format such as Africa/Tunis. At runtime, when you need a moment for calendaring, apply the time zone to the date and time to dynamically determine a moment according to the now-current time zone rules. In Noda Time, you would retrieve a LocalDateTime and time zone, to produce a ZonedDateTime for calendaring. That means it would be better to use only date, time and time zone. [2024-02-04 12:00 @America/Vancouver] The TZ database is assumed to know any daylight saving time changes, and can re-calculate it correctly in future. There is difference with events which are not too far, and those which are far in future. > - We sh
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 time zone you can know the offset (Google it, for > example).. Then, given the time zone and the local time, you can > know UTC. If orgmode gets the UTC there is not ambiguity. Majority of people do not use UTC. Having time displayed in UTC would and will confuse too many people, unless such time is only for logging purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant for a human. Internally, in calculations, program shoulde find time time zone, UTC offset, calculate, go to UTC, again to time zone, and again represent proper time. And if not that way, in any case there is complexity involved. Here is also good reference telling people how to program and work with time zones. Working with Time Zones: https://www.w3.org/TR/timezone/ > But, that would mean that the offset related to the different time > zones must be downloaded and updated from some site. For past timestamsp, one could store such as UTC time, and such time may be easily represented in presen time, it may be viewable in local time if computer program consults the time zone database. For timestamps we are making now, to record something, when it happened, we could use UTC time, but only for logs and similar, not so important time representations, which we will not revisit too often in future. But let us say for some future, timestamps in DEADLINE, SCHEDULED, those timestamps related to human, the UTC offset in this case cannot be so sure, because it is in the future, and it is vague as it could change politically. So the future will know what will be the UTC offset. > As you said before, that offset can change. For example, peninsular > Spain has the same time as Berlin, but as this doesn't make much > sense, it could change, so updates would be necessary. That is right. Even the time zone designation (name) could change in future, but for that reason, if we use today a time zone, the future time zone database will know about time zone that (was) defined today, and computer program will know how to calculate representation of the time in local time in future, for the time of today. Time zones are updated regularly, but we cannot be sure of it in case of atomic war or other planetary commotions. ☹️ I wish people could love each other more. ☮️ -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 > - Daylight saving time (British Summer Time (BST), UTC +1) > starts March 26, 2023 The above examples are not good enough, for following reasons: - in your example, you did not show other time zone but UTC time zone, plus the UTC prefix. - in the above shown example, there are time zones shown, plus the UTC prefix, and that is how it should be > Note UTC +0 and UTC +1. Yes, but in your example, if I remember well, you used @ (now I cannot be sure), so if you used @UTC+1 for me that would mean you are using the time zone named "UTC" (I just assume it can be used as time zone as it exists on my side in the database as well as one of time zones) and then you added the UTC prefix too. That is not compatible with each other. If you use UTC time zone, prefix is always +0 or nothing. If you use time zone other than UTC time zone, then prefix will be there. > I've seen such format in multiple time websites. That is fine, sure, I have seen it too, though your representation and those examples have difference. > On the other hand, TZ POSIX is reverse from what is commonly meant when > displaying UTC +1. POSIX is for computers, that is how I understand it, time zones, UTC offsets, they are rather for human. > > I think it is incorrect time stamp. If you specify UTC, you do not > > specify UTC offset. > > It is a correct TZ value 🤷 Time zone value? That is what I meant, and that is how I understood it as "time zone value" and it's label was "UTC", and then in that case UTC offset can't be there, as it is contradictory to show UTC offset with UTC time as UTC time has no UTC offset. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info
* 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 follow it. > For example > >[2023-10-29 02:30 @Europe/Berlin] > > is ambiguous. Period. You may put as many periods as you want. If you do not know how to generate timestamp that they are conclusive, then they will be always invalid or ambigous. Computer program that knows that your timestamp is most probably try to correct it, as saving time with invalid timestamp with some programs does not work, as I have demonstrated. Fact is that some timestamps mentioned in the conversations are invalid. Such invalid timestamps were generated by human, not by computer. Agree on what people internationally agreed. Do not generate it in first place. I can place any kind of text anywhere and I could say it is "timestamp", but that is valid for me, not for community that relies on international agreements. If user wish to do timestamp generation by hand, or some looney program wish to generate invalid timestamps, I can only say "good luck", but it is good to warn users and file bug reports for such program. Timestamp of course may be generated by human, and it can be ambigous. But why would you do that? Isn't it better to learn how to write non-ambigous timestamps? Or even better, to use good program to generate non-amgibious timestamp? Every user and programmer should strive to make computer, in this case Org program, to generate and calculate useful timestamps and how to increase that usefulness for users by being accurate. Programmer should not strive to generate invalid timestamps, and then prolong discussions how timestamp is invalid. That is programmer's problem. We have that problem in Org, solutions are in sight. It is not international problem at all as it is solved by ISO representation. All computer programs should use the internationally accepted time zone database and not those invalid timestamp representation but valid timestamp representation. And user should file bugs when they see that timestamps are either incorrectly represented, invalid, or there are some problems. It is easy to observe how will PostgreSQL understand those times with time zone being Europe/Berlin: Here it will tell that time of 01:30 has UTC offset of +02: select '2023-10-29 01:30:00'::timestamp at time zone 'Europe/Berlin'; timezone 2023-10-29 01:30:00+02 (1 row) Here it will tell that time of 02:30 has UTC offset of +01: select '2023-10-29 02:30:00'::timestamp at time zone 'Europe/Berlin'; timezone 2023-10-29 02:30:00+01 (1 row) Here it will tell that time of 02:30 has UTC offset of +01: select '2023-10-29 03:30:00'::timestamp at time zone 'Europe/Berlin'; timezone 2023-10-29 03:30:00+01 (1 row) Observe how the timesamp representation changes from '2023-10-29 01:59:59+02' to '2023-10-29 02:00:00+01' and how UTC offset is there to make it very clear. select '2023-10-29 01:59:59'::timestamp at time zone 'Europe/Berlin'; timezone 2023-10-29 01:59:59+02 (1 row) select '2023-10-29 02:00:00'::timestamp at time zone 'Europe/Berlin'; timezone 2023-10-29 02:00:00+01 (1 row) Above is happening because PostgreSQL observes time zone definition and knows how to represent that timestamp correctly. A looney program will not observe time zone, it will generate invalid or ambigious timestamps. Conclusion: --- Do use looney programs. Use timezone database information and international standards to represent and exchange time related information. > It would also be nice to eventually recognize, that we are talking > about readable syntax for humans, that is sometimes generated, > sometimes manually typed. Most of you comments does not really > resonate with this crucial design goal. Teach that human how to represent time correctly. Teach computer program to help human to correct incorrectly hand written timestamps to something that is reasonable, like Etar calendar does that. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 maintaining it. Specifying time zone is not ambiguous as long as you use the TZ database for specifications! > [2023-03-29 02:30 @Europe/Berlin] is special. I may only guess you wanted to specify the last Sunday in March 2023, where there is UTC offset shift. Your time stamp above is very valid, but you probably wanted to point out to the alleged problem with the daylight savings. The time stamp you maybe wanted to demonstrate would be: 2023-03-26 02:30 @Europe/berlin It is not special case! It is INVALID time stamp. It does not exist in the context of internationally agreed time. In the context of this e-mail, you may write what you want, but you are arguing about something that does not exist. Things that do not exist, do not make you a problem. The only thing that could be ambiguous is the hypothetical, imaginary, lousy software that generates invalid time stamps like that. You are bringing up the problem which in the human agreed reality does not exist. > According to https://www.timeanddate.com/time/zone/germany/berlin, > 2023-03-29 is the time when the clock is shifted one hour back due to > the daylight saving transition. The wall time goes like > > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> > 2:30 (again!) I got your point, even though you are showing invalid time stamp. And that is not a problem, because TZ database specifies exactly how to calculat time. If you however, use time zones but do not use time zone database, well, that is case of bad program design, and your program, and anything you do in that program will become ambigous as well. > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: > before and after the transition. 1. Your timestamp is wrong for demonstration purposes, the time stamp you are displaying is not related to daylight savings shift. 2. The time stamp for demonstration should be: 2023-03-26 02:30 @Europe/berlin 3. The time stamp above, in the number (2) of this list, IS INVALID. 4. Recommendation is to stop using lousy programs generating invalid time stamps. > Specifying explicit offset is thus necessary in this specific > scenario to disambiguate the timestamp: That specification of UTC offset is necessary is out of any doubt. But you have formed your decision in invalid timestamp and lousy programs, thus further conclusions based on such decisions cannot be relevant, and people shall be cautious regarding conclusions that were based on wrong and correct time stamp, where author wanted to point out to daylight savings shift time stamp, whereby such time stamp is invalid and as time representation does not exist. It is because you do not need to worry how time zone is ambigous, because it is not. Please read specification of the time zone definition. It has been defined to solve this type of problems for people. > [2023-03-29 02:30+2 @Europe/Berlin] (before transition) > [2023-03-29 02:30+1 @Europe/Berlin] (after transition) Both of the above time stamps do not exist, both are valid. If you meant daylight savings time stamps, then you maybe wanted to say following: > [2023-03-26 02:30+2 @Europe/Berlin] (before transition) > [2023-03-26 02:30+1 @Europe/Berlin] (after transition) However, above time stamps are INVALID. You deal with non-existent problem. There is nothing to solve there. Practical exercises for people to understand it: Go in shell: # Following will set your user's time zone to Europe/Berlin, that # indicates that programs shall look for time zone specification, such # as the one in /usr/share/zoneinfo/Europe/Berlin $ export TZ=Europe/Berlin # In the next step, setup the date: $ sudo date -s '20230326 0159' Sun Mar 26 01:59:00 AM CET 2023 # Ask for current time stamp from system $ date 2023-03-26-01:59:22-Sunday # Sorry that I have peculiar system time stamp personally, it is # because I often use it to generate files # Let us see it without my customization $ /usr/bin/date Sun Mar 26 01:59:06 AM CET 2023 # Let us repeat it, while we let time running: $ /usr/bin/date Sun Mar 26 01:59:32 AM CET 2023 # Observe what is happening: $ /usr/bin/date Sun Mar 26 01:59:58 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 01:59:58 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 01:59:59 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 03:00:00 AM CEST 2023 Did we arrive to 02:30? No. Why? How about setting up the date to the imaginary "ambigous" and invalid time stamp: $ sudo date -s '20230326 0200' date: invalid date ‘20230326 0200’ $ sudo date -s '20230326 0230' date: invalid date ‘20230326 0230’ Hmm. Maybe the GNU `date' command simply does it's job well?
Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]
* 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 we observing public inbox bug? Sorry for that. It was not intentional. It happened during the exercises. I went to future, and wrote from there. ☺️ Now it is pending until the future time stamp. Similarly, I have made mess with Dino XMPP messenger as well, I have sent message from future, now that message will appear to me for years as the last message sent, no matter what I do, that message remains pending! Why did mailing list accept message from far future? It should not be so, that is bug to be reported. Dino messenger accepted message from far future, that is bug, and I have reported it: https://github.com/dino/dino/issues/1355 -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 above format is unclear to me. I look at timestamps every day, too > > many, often change them. > > > > I cannot understand what you mean. > > See "std offset" format for TZ environment variable. > https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html I understand that information on hyperlink. I do not understand how it is related to "UTC", a with "UTC" people do not put UTC offset. It is either UTC as time zone and offset can be considered only ZERO, like +0, or it is NOT UTC as time zone, and there is offset to understand what was really the UTC. This latter is also explained in that hyperlink. So what do you really mean with such time stamp? I think it is incorrect time stamp. If you specify UTC, you do not specify UTC offset. There is no UTC offset for UTC time. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info
* 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. > > A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin". > Strictly speaking, this point in time does not exist, because in the > night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00 > directly to 03:00 in the time zone Europe/Berlin. Therefore the > /interpretation/ of this timestamp is ambiguous. Thank you! The generation of invalid time stamps is programming bug. > The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This > point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and > 02B:30 (02:30 UTC+0100) in this night of switching back from DST to > normal time! > > So, in general, only using the time zone name may indeed lead to > ambiguous interpretations of timestamps. Exactly! Thank you! With the correction that "this point in time really exists twice" -- well, not like that, you have specified 2 different time points by specifying different UTC offset, so those are different time points. Though I got your ▲ -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 savings transition hour for those locations which have daylight > > savings? Keep[ing in mind that the complexity is less to do with the > > time stamp format and more to do with using that information in any > > meaningful sense. This, combined with the reduced readability of such > > time stamps and increased possibility of user confusion leads me to > > question if allowing time stamps with both offset and time zone together > > in the one time stamp is worthwhile. > > As I originally stated in the proposal, the real usefulness of combined > offset+time zone is asking Org to double-check the consistency: That is right, though that is not the fundamental reason for using UTC offset and time zone. Every good application should check if the time stamp is valid or not. It should not allow user to specify invalid time stamps, and it should not calculate and generate invalid time stamps. The reason for UTC offset is future possible political changes of the UTC offset. It shall be assumed that time stamp from past was correct, that it was generated by application that was using the time zone database, but the UTC offset in present time could be changed, just as it was mentioned for the Russian decision recently. By using UTC offset and time zone from past, one can then use present UTC offset definitions and calculate differences. However, there are still rare changes with the past time zone definitions. Using UTC offset for future time stamps is IMHO possibly much more problematic for the same reason of possible changes in future. > Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] > The time zone rules for Asia/Singapore may or may not remain the same > due to political uncertainty. Today, we expect the offset to remain +08. > If it changes in future, Org will warn the user. Very right. > In addition, I find specifying both the time zone and the offset > useful for readability: Thank you. > Complex time zones in timestamps will not rely on user's computer having > the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London] > unambiguously specifies the UTC offset yet emphasizing that the > timestamp is related to specific location (Europe/London, but not > Europe/Paris). In fact, one may somewhat abuse this format and specify > [1916-09-12 12:00+01 @France/Marseille] emphasizing the location. Then if they are not to relay on time zone database, on what they can rely as alternative? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 considered UTC time zone, then the only prefix for such time stamp is +00 and nothing else, or no prefix at all. The time stamps that specify UTC offset are expressed in local time, not in UTC time. Here are few examples of ordinary usage of UTC offset converted to UTC: 2023-01-07 09:21:11.019166+03 which means: 2023-01-07 06:21:11.019166 @UTC 2022-10-05 14:09:04.79737+03 which means: 2022-10-05 11:09:04.79737 @UTC Due to that ordinary usage of time stamps, something like @UTC+2 where you specify 14:00 o'clock, is unclear, if you mean UTC time plus 2, like 16 o'clock, or you mean 12 o'clock. Time stamps having UTC offset are in their representation such as in calendar tied to the time zone, as they maybe are derived from system time, where time zone need not be displayed in the time stamp, but it is nevertheless there and used by program to derive the UTC offset. And it is either UTC time, or local time plus UTC offset. There is no UTC time plus UTC offset, why would anybody need that as time stamp? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info
* 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 zone designations carry the fact of whether they are > supposed to be summer times or not with them (as with CET/CEST), > some not (as above). The time zone database is only known for a > limited time into future and may change with political > vagaries. Yadda, yadda. Very right. At least the history is more certain than the future in regards to time calculations with computer. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 if developers wish to provide accuracy of time calculations for users. Using the time zone is built-in, it is just matter of representation of time at export or exchanges. And time zone could be changed from the default system time, inside of the time stamp, if not there, inside of heading property, if not there, inside of the file time stamp property. That way majority of time stamps can remain how they are with addition of specification of time zone property. > Note that my proposal allows specifying the time zone when you need > it. Thank you! That is good proposal. > Or not specifying it and specifying the UTC offset only. If you mean, specifying _local time_ plus UTC offset, then that is not how you can exchange information with participants in meeting. That is unsure. But if you mean specifying _UTC time_ plus the UTC offset, that is alright to derive local time from it. Preceding condition is that such UTC time plus the UTC offset was calculated correctly. And there need not be the ultimate goal in Org that all kinds of time stamps can be calculated for the future. That shall be the job of the function to verify if the timestamp can be re-calculated or not, and function may warn the user to update it with missing time zone. Read "Putting It All Together" https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ Are you going to implement the connection to time zone database? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 the time when the clock is shifted one hour back due to > > the daylight saving transition. The wall time goes like > > > > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 > > (again!) > > > > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before > > and after the transition. Specifying explicit offset is thus necessary > > in this specific scenario to disambiguate the timestamp: > > > > [2023-03-29 02:30+2 @Europe/Berlin] (before transition) > > [2023-03-29 02:30+1 @Europe/Berlin] (after transition) > > OK, in that case, I think what we are in danger of here is letting > the perfect be the enemy of good. > > The problems of daylight savings transition points is fairly well > understood and I think it is fairly well accepted that there is > ambiguity arising from the use of daylight savings. The only ambiguity is if you miss to understand that "time zone" definition already contains specification of daylight savings. If you do understand it, then there will be no ambiguity at all. > 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 savings transition hour for those locations > which have daylight savings? That additional complexity is important for future, as we cannot know what will be the future UTC offset due to political changes! > Keep[ing in mind that the complexity is less to do with the time > stamp format and more to do with using that information in any > meaningful sense. That is very correct, that is why Org shall keep time stamps simple in it's basic form and allow users to specify precision as they wish. > This, combined with the reduced readability of such time stamps and > increased possibility of user confusion leads me to question if > allowing time stamps with both offset and time zone together in the > one time stamp is worthwhile. As we promote Org to be good for "reproducible research" then for those people will be of value, and many other groups who need time precision. https://html.duckduckgo.com/html/?q=org+mode+reproducible -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 cannot give time. > However, if you consider it in conjunction with a date and time, as > in 2023-03-23 02:30 @Europe/Berlin, then it isn't ambiguous - in > that case, it really just says 'Lookup the time zone offset in the > databse for Berlin as of that date and time. Exactly that. > Now that could change - for example, the German government might > make a temporary or permanent change that would change the offset > from UTC for that date+time the day after I look at it (or export > it). It cannot change in past. It will not change drastically or capriciously as Germany aligns with other countries and ISO standard. It is more likely that ISO non-members deviate from international coordination of time related definitions: ISO - Members: https://www.iso.org/members.html > Personally, I cannot see the use case of including both a fully > qualitifed time zone (as in @Europe/Berlin) and an offset, but I > also don't know all possible use cases - there could well be use > cases where you want/need to record both the location time zone as > well as the offset at the point when you recorded the timestamp. Time Zones vs. Offsets – What's the Difference? Which Is Best?: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ Quoting: - Given a time zone and a UTC time, you can know the offset—and therefore the local time. - 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). - Given UTC and an offset, you can know the local time. - Given a time zone and an offset, you don’t know much. - That’s why a calendar systems work with time zones, offsets, and UTC; - we need the offset to go from local time to UTC, and we need the time zone to go from UTC to local time. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 that. Help me with understanding. Which two points in time does it refer? When I use time zone Europe/Berlin, it only refers to following time stamp: 2023-03-23 02:30:00+01 What is the other point in time that it refers to? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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. > > > > 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 time zones in advance, so > > there are few changes that people cannot plan in advance. > > Please see Russia's plan to put Eastern Ukraine on Moscow time, and then > come back and argue that people on this planet agree on time zones in > advance: > > https://www.nytimes.com/2023/01/27/world/europe/russia-ukraine-time-zones.html?smid=url-share Then I have not expressed me enough specific. When I said "people", I definitely did not think "all people", as that is impossible. The agreement of "people" is summarized by standards of International Organization for Standardization (ISO) with ISO 8601 that includes specification and representation of time and time zones. There may be many disagreements on the world in relation to time zones, and if they do not align it for international standard, we do not need to consider it. While it may be specific disalignment problem in some country, their citizen must anyway resort to ISO again for calculations. We all rely on ISO standard. Not capricious decisions going behind that. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 time zones in advance, so there are few changes that people cannot plan in advance. Those changes are recorded in time zone databases. Unless you consider programming without using time zone databases, then I can surely understand that it will be ambiguous. > To resolve the ambiguous, we should either introduce DST flag DST is property of time zone. You do not introduce it, you read it from time zone database. But maybe you wish to implement time zones in Org. In that case I can only say "Good luck" to accuracy. > or simply allow specifying the UTC offset directly. UTC offset is not reliable, and is also derived from time zone database. Try it out, make tests, create experiments, compare if that approach will be usable, publish it and put in for testing. > Since DST is not guaranteed to be +-1 hour (it may be more, up to 1 > full day), DST flag is more problematic than UTC offset. Is not if you always pull the latest tz database. Political changes are pretty careful to people and decisions are announced ahead of the change. So do you think that you cannot use tz database in Emacs Lisp? Maybe it will be necessary to make new Lisp functions defined in C language, accessing the time zone database. But it is not for Org to implement new tz database in Emacs Lisp, that will become unmaintainable work. But why not, if you wish, but accuracy of time will be questionable. Researching following pages will give you idea with what you are trying to deal with on Org level: How to Read the tz Database: https://data.iana.org/time-zones/tz-how-to.html List of tz database time zones - Wikipedia: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones tz database - Wikipedia: https://en.wikipedia.org/wiki/Tz_database -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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 use full timestamp range syntax > >>[2022-11-12 8:00+03]--[2022-11-12 22:00+08] > > > > I have already explained today that above calculation cannot be > > unambigous. Please verify my references and practical examples. When > > user thinks that span is X hours, the real span could be X-1 or X+1 > > This has been discussed in the previous emails. > Consider that you are running a scientific experiment around daylight > saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the > government decided that the wall clock should go like 2:15 -> 2:59 -> > [CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not care. You just need > to make sure that the experiment runs exactly 3 hours without trying to > consider the currently used TZ rules. Sorry, I cannot see how running the experiment three hours long is related to exchange of for example, appointments, or calendar events that shall be represented in possibly different time zones. It seems you have different personal purposes for time representation in Org. How about making a list, why at all are you doing it? Is it for scientific experiment that you run in your place 3 hours? Or for people travelling or exchanging times. Are you sure that telling not to care is good notion? Why not simply give up on setting up times correctly? > In contrast, writing [2022-10-29 2:15-5:15 @Europe/Berlin] is > ambiguous as it may imply both 2:15CEST-5:15CET (4 hours) or > 2:15CET-5:15CET (3 hours). Why don't you make the experiment and show how it is ambiguous? Where is the error in this comparison of Europe/Berlin time and CET time? Is daylight savings change what you expect? I am not sure and I am asking you about this. Here is practical example, is there anything wrong? How is it ambigious? 2022-10-29 02:15:00+02 | 2022-10-29 01:15:00 2022-10-29 02:20:00+02 | 2022-10-29 01:20:00 2022-10-29 02:25:00+02 | 2022-10-29 01:25:00 2022-10-29 02:30:00+02 | 2022-10-29 01:30:00 2022-10-29 02:35:00+02 | 2022-10-29 01:35:00 2022-10-29 02:40:00+02 | 2022-10-29 01:40:00 2022-10-29 02:45:00+02 | 2022-10-29 01:45:00 2022-10-29 02:50:00+02 | 2022-10-29 01:50:00 2022-10-29 02:55:00+02 | 2022-10-29 01:55:00 2022-10-29 03:00:00+02 | 2022-10-29 02:00:00 2022-10-29 03:05:00+02 | 2022-10-29 02:05:00 2022-10-29 03:10:00+02 | 2022-10-29 02:10:00 2022-10-29 03:15:00+02 | 2022-10-29 02:15:00 2022-10-29 03:20:00+02 | 2022-10-29 02:20:00 2022-10-29 03:25:00+02 | 2022-10-29 02:25:00 2022-10-29 03:30:00+02 | 2022-10-29 02:30:00 2022-10-29 03:35:00+02 | 2022-10-29 02:35:00 2022-10-29 03:40:00+02 | 2022-10-29 02:40:00 2022-10-29 03:45:00+02 | 2022-10-29 02:45:00 2022-10-29 03:50:00+02 | 2022-10-29 02:50:00 2022-10-29 03:55:00+02 | 2022-10-29 02:55:00 2022-10-29 04:00:00+02 | 2022-10-29 03:00:00 2022-10-29 04:05:00+02 | 2022-10-29 03:05:00 2022-10-29 04:10:00+02 | 2022-10-29 03:10:00 2022-10-29 04:15:00+02 | 2022-10-29 03:15:00 2022-10-29 04:20:00+02 | 2022-10-29 03:20:00 2022-10-29 04:25:00+02 | 2022-10-29 03:25:00 2022-10-29 04:30:00+02 | 2022-10-29 03:30:00 2022-10-29 04:35:00+02 | 2022-10-29 03:35:00 2022-10-29 04:40:00+02 | 2022-10-29 03:40:00 2022-10-29 04:45:00+02 | 2022-10-29 03:45:00 2022-10-29 04:50:00+02 | 2022-10-29 03:50:00 2022-10-29 04:55:00+02 | 2022-10-29 03:55:00 2022-10-29 05:00:00+02 | 2022-10-29 04:00:00 2022-10-29 05:05:00+02 | 2022-10-29 04:05:00 2022-10-29 05:10:00+02 | 2022-10-29 04:10:00 2022-10-29 05:15:00+02 | 2022-10-29 04:15:00 -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
* 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/ >2022-07-08T02:14:07+02:00[Europe/Paris] The above looks nice, though not as clear from human view point as compared to standard Org time stamps, which are very readable. > 2. https://www.loc.gov/standards/datetime/ does not contain any new I would disregard above, as that is US government, not international document. Reason why they use UTC offset alone is that they decided they do not need more than that. Org is international and should not be bound to US only. >-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]? >-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>] >Examples: >2022-11-12 12:00+02 # 12:00 UTC+2 >2022-11-12 14:00+0230 # 14:00 UTC+2:30 >2022-11-12 14:00-0230 # 14:00 UTC-2:30 >2022-11-12 14:00Z # 14:00 UTC It looks nice, but I have demonstrated that calculations by using UTC offset can't be accurate. Please disprove and rectify me, by using practical examples, you could disprove my practical example offered previously. >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 use full timestamp range syntax >[2022-11-12 8:00+03]--[2022-11-12 22:00+08] I have already explained today that above calculation cannot be unambigous. Please verify my references and practical examples. When user thinks that span is X hours, the real span could be X-1 or X+1 > 3. (1) and (2) can be combined > >2022-11-12 12:00+08 @Asia/Singapore That is how it should be, the UTC offset combined, with the time zone. And I suggest avoiding such timestamps by default, rather using time stamps as usual, and having heading time zone property, file time zone property and Org using system time zone in absence of any of them. Providing practical example or functions on how to calculate it should give better feeling which way will be better. This is very simple timestamp, readable, with weekday: <2023-01-31 Tue 16:13> I propose to remain that way, how it is, with addition: 1. If user wish, could add time zone, including UTC offset. Adding only UTC offset makes no sense, and adding time zone without UTC offset will cause difficulties in future. Thus: <2023-01-31 Tue 16:13+03 @Africa/Nairobi> 2. Otherwise heading could have time stamp when necessary to distinguish it from other headings: * My heading :PROPERTIES: :TIMEZONE: +03 @Africa/Nairobi :END: Then this time stamp <2023-01-31 Tue 16:13> would 3. Otherwise file could have time stamp, if necessary to distinguish it from other files on the same system: #+TIMEZONE: +03 @Africa/Nairobi 4. Otherwise system time zone That way you only upgrade time stamps with UTC offset and time zone, only when necessary, leaving everything else how it is, with addition of better calculations and related functions. All of the timestamps, including those simple existing one like <2023-01-31 Tue 16:21> in Org can be made unambigous in their representation or exchange by using UTC offset, plus the time zone, by using those properties. And very good reference on that link: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ Although serialization with offset time zones is supported in this document for backwards compatibility with java.time.ZonedDateTime [JAVAZDT], use of offset time zones is strongly discouraged. In particular, programs MUST NOT copy the UTC offset from a timestamp into an offset time zone in order to satisfy another program which requires a time zone annotation in its input. Doing this will improperly assert that the UTC offset of timestamps in that location will never change, which can result in incorrect calculations in programs that add, subtract, or otherwise derive new timestamps from the one provided. For example, 2020-01- 01T00:00+01:00[Europe/Paris] will let programs add six months to the timestamp while adjusting for Summer Time (Daylight Saving Time). But the same calculation applied to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result that will be off by one hour in the timezone Europe/Paris. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 view at the beginning you were promoting that Org must use > purely UTC timestamps just because PostgreSQL recommends timestamptz > type. I am not promoter of "UTC timestamps", you have mixed me maybe with some other person. Last time you misquoted me. That PostgreSQL recommends time stamp with time zone is only in so far related to Org as for program design decisions. There is plethore of other programs using time, just look in any calendar and underground. I do not promote anything, I give suggestions to developers to make decisions that will not impact people. My proposal is not that what you describe, but I will repeat it here for clarity: - Timestamps may be left how they are now with small addition - Time stamp could get time zone (I never said UTC, neither UTC offset) -- I would myself never suggest to people to place timestamps in time zone, but to simply use the local system time zone. Case to use time stamps with time zone would be then when such time stamp is isolated in the whole Org file and as such, the task has to be sent to other people, shared, or published. This is finely grained. - Heading could have time zone property, then all time stamps in that heading would easily be calculated for sharing purposes. - If not heading, then user could set up file #+TIMEZONE property, if such is or should be different to system time zone - Without any settings in Org, Org may use system time zone to calculate future time difference. And I said that is in Emacs Lisp similar to logical OR: timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-ZONE So please do not misinterpret and reiterate what I never proposed or suggested. > Now you are insisting that every timestamp must have timezone with > rules describing DST and other transitions. Absolutely not, I cannot find myself in your description. > In both cases you are doing it with excessive passion. You are free to describe it as you wish. And? > Currently you are arguing with people who have already agreed that > location-based timezones are important, e.g. Tim and Thomas. I am in > doubts if it is helpful to someone. I do not argue with people nothing as because of their name or position, as people are not object of discussion. Neither my last writing was related to "location based time zone" but to UTC offset. All my writing is directed to Org developers to get access to references before making any decisions how to calculate times. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
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 our mutual understanding. > But an offset does not need a time zone to define a time. I am trying to understand what you wanted to say with the above. Before representing time with the UTC offset: - To derive the representation of time with the UTC offset, one needs time zone, as UTC offset is defined in the time zone. That is what you also said above. After representing time with the UTC offset: That time is defined, and at that time point does not need time zone. I am not concerned of time representation after UTC offset has been derived, but of programming calculations to users' local time, as for example in Org Agenda. > For example, true mean local solar time of a specific longitude can > be described by UTC plus offset. Solar time - Wikipedia: https://en.wikipedia.org/wiki/Solar_time By meaning that solar time should be related to longitude, I am totally with you Heinz. It is also true that one could disregard the definition of UTC offset from the political reality, and calculate it absolutely. That condition I have already mentioned, when I said, that means we are making "new type of time" in Org, if we start calculating it that way. The meaning of "UTC offset" is however, political. Please see the UTC offsets here: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png Look at the map, find Kazakhstan with UTC offset +6 on the same longitude with Russian Federation with UTC offset +5. Observe Kazakhstan with UTC offset +6 on the same longitude with China with the UTC offset +8. That alone should tell you that solar time is not really related to UTC offset, but we could say it is "approximate" with few hours more or less. Of course you can describe solar time with UTC offset, but do not assume it will be accurate. > I agree with your criticism of "They refer to local *solar time* at a > particular place." This is written in > https://en.wikipedia.org/wiki/UTC_offset , but not even there the > description is consistent. We can say it is approximate what they mean. > Of course, for every finite offset, we can find a corresponding > particular place (a longitude). I wish it would be so, but it is not so. It is approximate, just look at the map. And please tell me if after this you still think there is something wrong? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 attempts by many to explain why what you are > sending is adding little value. > > I was simply responding to your response to Sterling's glossary of > definitions where you argue against defining offset (the term) as a > fixed value. > > I will not be engaging with you further. UTC offsets have been assigned by authorities, that they are political, change due to daylight savings -- and for that reason cannot alone as such be used for calculations of time, for example in Org Agenda. I fully understand that representation of time with UTC offset alone is as such fine and good, never said anything opposite. Adding some hours, days, as absolute time to it, or deducting, it is of course always possible. 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. My intention is of course not what you stated. I have not get bad intentions. Please do not assume it. You got references showing that it is politically related, that UTC offset does change suddenly, and for that reason one cannot just use it for calculations in program. I am fully aware and never stated different, that once you place UTC offset as representation somewhere in text, that it is offset from UTC time and that time point is fine and remains fixed. What I am saying is that calculating that time point to local time is tricky, as using UTC offset alone is not going to give accurate local time unambiguously. Sometimes it will give, but sometimes not if programmer uses direct calculation. "fixed" is thus only fixed in context of representation. I was thinking we speak here of using time objects for calculating times in future, not only of representation, as I did not argue about it. UTC offset is representation as it has to be derived from time zone to be represented as such. Provided that program knew how to derive correct UTC offset, that is "fixed" as representation. Programmer can now add some time or deduct some time and directly added or deducted time will also represent some point in time. But will it be that time that user was thinking for another user in different time zone? Unambiguously is not possible to use only UTC offset for such calculation, due to reason that UTC offset changes how authorities decide on it. Let me try to make exercise example both for me and other people, and feel free to correct me: From: https://www.timeanddate.com/news/time/europe-starts-dst-2022.html , | Daylight Saving in Europe | | Time changes in Europe are synchronized. According to the current EU | law, DST starts on the last Sunday of March and ends on the last | Sunday of October. Participating countries are: | | The European Union (EU), including Bulgaria, France, Germany, | Italy, Poland, and Spain. ` - Last Sunday of March in 2022 was 27th March 2022, or 2022-03-27 - the clock forward had to be done at 1 hour UTC time on March 27th 2022, because Berlin before 27th March 2022, was with UTC offset +1, that time should be 2022-03-27 01:00 UTC time, which is also same as Berlin time. - Let us say one second after 2022-03-27 01:00 UTC time or UTC +1, the clock will not be 2022-03-27 01:00 UTC, but 2022-03-27 02:00 UTC, loosing one hour, as clock moved forward. UTC offset changed suddenly. - person in Berlin plans meeting for on 26th March with somebody in China, for 27th March 2022 at 10 o'clock, how is he going to represent this? Let us see, maybe as following. <2022-03-27 Sun 10:00> - on 26th March 2022, the UTC offset in Berlin was +1 - on 26th March 2022, when user exports that appointment, the time was for example 16 o'clock, something like 2022-03-27 16:00+01 because UTC offset was +1 at that time. - If Org programmer decides to use UTC offset only for calculations, then the program will know that UTC offset in China is +8 hours. - What will program do? By using UTC offset only, program will know that now is 2022-03-27 16:00+01 and that timestamp like <2022-03-27 Sun 10:00> is also with UTC offset +1 (which is not true). But program would think it is 2022-03-27 10:00+01 if program uses UTC offset only. - Program may wish to provide new UTC offset for Chinese user, by knowing that in China on 26th March 2022, at 16 o'clock is +8 and not +1, the difference of 7 hours will be added on the time stamp of appointment, which is 2022-03-27 17:00+01 - However the time of 27th March 2022 at 10 o'clock Berlin time the time in Shanghai was 16 o'clock. - While Chinese user was in restaurant at 16 o'clock and waiting for appointment at 17 o'clock, because he ha
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 due to various reasons, such as > daylight savings time, which also means the offset for that timezone > changes. Including that offset for that time zone can be changed for political reasons, and did change in past, and some time zones may multiple UTC offsets. > However, it is the time zone definition which has changed. Yes, and that change is about UTC offset. As time zone represents location but UTC offset must be tied to it, otherwise how would you know what time has the time zone? > When you specify a date+time wiht an explicit offset, that offset is > fixed. It is fixed for that time moment. I have not said anything different. I am only worried that if calculation go straight from UTC offset to UTC offset without observig time zones, one will get proper UTC time, but not proper representation in users' time zone. I do believe that Org developers will make right decisions. > That date+time is fixed. It will not change when daylight davings > comes in or goes out because it isn't a time zone. It is only an > offset and has no location reference and therefore no time zone. For the above, I have already sent a map, by only observing the map, one can see that time offset is directly related to time zone, it is property of time zone, and it will change depending of political changes, and it does change with daylight savings time. I have given enough references, feel free to read it. What does not change is the fact that UTC offset representation will accurately provide UTC time. >From UTC time, by using user's time zone and various embedded parameters one could arrive to user's local time, including users UTC offset. Excercise: When there is daylight savings time (clock goes forward or backward), it shall be clear that UTC offset changes as well. That means one hour more or less must be accounted for in every calculations of Org Agenda. But by using UTC offset alone, one cannot even include daylight savings time changes! As for that one needs time zone. Here is another good reference: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ , | Our Example | | America/Coral_Harbour is a time zone (for simplicity, I will focus | only on IANA* time zones). America/Detroit is a time zone. With laws | as they are now, the America/Coral_Harbour time zone has an unchanging | offset of -0500, or five hours “behind” GMT, which for our purposes | here matches UTC. America/Detroit changes during the year from an | -0400 offset to an -0500 offset. So sometimes, the good people of | Coral Harbour and the good people of Detroit have the same | offset. Sometimes, they don’t. ` What do you think, is that information true? Does UTC offset "change" or "remain fixed"? Is it possible for programmer to convert UTC offset by using direct calculations? Or programmer needs to know information about time zones? This makes calculations of Org Agenda or future time stamps difficult when using solely UTC time offset. Time offset is best expressed as representation of time at that time point, and is always derived from the time zone. > 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 trying to give you references that you understand what people agreed on this planet. I never said that time zone has fixed offset, some time zones have it fixed, some not, as UTC offset changes for daylight savings and political reasons. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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. Above are not my words, I do not use those fat dots. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
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 the sake of people using Org mode. So let me gently try explaining it with different words. > UTC offset exists without time zone. I have already stated that UTC offset is property of a time zone. Single time zone may have different UTC offset. A time zone must have UTC offset as it's property, as how else would people know what time is in Berlin/German? Is it by guessing?! So for that reason on this planet countries agreed politically to define one or more UTC offset for every time zone. UTC offset is thus always derived from the time zone. That it "exists without time zone" is something individual, but when we speak of UTC offset, we know that it was derived from time zone. What we cannot know unambiguously is from which time zone it was derived. > UTC is absolute time As we know absolutes are impossible, especially about representation of "time", we people have only agreed on how to define UTC time, that is what we count internationally. Let us assume it is absolute. > and offsets from it do not refer to political time in a time > zone. It is good to observe the map to understand if UTC offset does not refer to political time or maybe it does? All time zones have their UTC offsets, as otherwise we would not be able to calculate time by sole name of city like Berlin, so Berlin must have defined UTC offset, and all time zones, from which UTC offsets are derived are politically decided, this includes UTC offset, which are very much political or in other words they are decided by people in power or in authority. > They refer to local *solar time* at a particular place. They maybe should so, but that type of solar time is also politically decided, it is not something calculated or really accurately pinpointed time. You may observe it on the map, and decide if it really refers to solar time or solar time is politically decided, or maybe something else? Solar time is also not much relevant for Org, as what I would like to see in Org is precision with time calculations. While I cannot guarantee for accuracy of these maps, it will be beneficial to look at them and make a practical exercise. Look at this nice map with time zones and UTC offsets: https://qz.com/wp-content/uploads/2015/03/map.jpg?quality=80&strip=all&w=3000 I guess that only by looking one can see that it cannot be possibly accurate "solar time", but we can speak of approximate solar time, as differences of 1-4 or 5 hours in solar terms is nothing so special. Anyway, solar time is not important for programming calculations. What we wish to observe is not to make mistake in programming by using UTC offset incorrectly, as IMHO, that alone would be poor choice for Org developers to stick to it. Excercises: --- 1. Observe that tim zone in Iran has offset of 3.5+ hours, while North from Iran at the same Earth longitude in Turkmenistan, there is offset of UTC 5+ -- solar time can't be accurate that way. 2. UTC offset depends on time zone, it is the property of time zone. See the map to understand. 3. UTC offset may be changed by decisions of authorities and is dependant on daylight savings and political changes, as it has to be derived from time zone. 4. By using UTC offset one can find UTC time, like Max say, that is for many applications alright, but it will not make it accurate. I am reluctant to accept that UTC offset is enough, unless it is demonstrated that it will bring the intended purpose in Org. As that is just one parameter that is derived from time zone. That is not how other applications work, they will either store time in UTC, or time with time zone representation including UTC, plus including the UTC offset. One need time zone to understand and calculate future times for people who change time zones, for example in Org Agenda, as by using UTC offset only, one would need to first convert it to time with time zone of the user viewing that time, and then to UTC offset of the user viewing that time representation. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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. It is always pleasure to see how I missed it. I suggest that you define the problem in Org mode for purposes of calculations. That way you can solve issues. > > > > > made the observation" > > > > >• e.g., 2007-02-03T04:00:00.000+01:00 > > > > > > > > Offset is not that fixed, maybe from viewpoint of storage as maybe it > ... > > > I think your misinterpreting the intent here. If you specify a timestamp > > > with offset, it is fixed. > > > > That is what you say. And I am pointing out to international standard > > references. > > You reference and verbose message are hardly relevant. Since something has > already happened, time offset is known. DST can not change it, either it is > effective or not at this moment. > > 2007-02-03T04:00:00.000+01:00 > > can not be unambiguously attributed to an IANA timezone ID, however it > precisely specifies UTC time (time in seconds since epoch, etc.). Yes, and I do not say different. We understand each other in it. > Usually (but not necessary) it means 04:00 local time in a timezone 1 hour > ahead of UTC that moment (you may use it to specify 05:00 in timezone having > +02:00 offset). It is enough for a lot of applications. If you are sure, of course, go ahead, I am not sure that using UTC offset, alone, is good idea for future time calculations. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch))
* 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 the question of linking to emails. > Obviously Emacs caters to a tiny niche, yes. But how does > it do or should do? Thanks for comments. Emacs is used by many millions of people, at least installed. Not maybe daily used, real number of users is difficult to determine. Though Emacs users of Emacs e-mail packages must be less. Still it must be a significant number of people. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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, it is hard-coded
> and unrelated to the browse-url-handlers:
>
> defvar thing-at-point-uri-schemes
>
> the list is rather long.
Yes, there are official, unofficial, and just that it is not user
option means nothing much, I am adding to that list what I wish by
using `add-to-list' function, as just as `load-path' variable cannot
be customized with "customize", it can still be changed with
`add-to-list'.
> Developer must consider other features that may be affected by demanded
> changes. False positives are acceptable for thingatpt and goto-address-mode.
> For Org mode balance is different. Too greedy regexp to recognize links may
> have detrimental effect on export and publish, not to mention that links may
> need special treatment. In addition Ihor mentioned fuzzy links.
I got it.
How I understand it, Org should be more deterministic and for that
can't use other available libraries.
> > Org should now hard code new way of opening URL schemes, but use Emacs
> > settings.
>
> Try to derive list of supported schemes from `browse-url-handlers'.
browse-url-handlers ➜ (("gemini:" . elpher-go) ("gopher:"
. elpher-handler-go) ("about:" . hyperscope-about) ("hyperscope:"
. hyperscope-url) ("e2dk://" . amule-handler))
it is user option to be customized.
It is obvious that my idea that URL schemes should be unified may be
reasonable, but there is not enough programming functionality in Emacs
to allow it to be very deterministic. And thus Org has to make it's
own URL handling. That is how I understand, correct me if this is
wrong.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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) > >> • This captures the idea of "when did it happen for the person who > >> made the observation" > >> • e.g., 2007-02-03T04:00:00.000+01:00 > > > > Offset is not that fixed, maybe from viewpoint of storage as maybe it > > is considered fixed in it's representation, but you have to keep in > > mind that time offset by it's definition is changing itself, suddenly, > > depending of daylight saving and time zone. > > > > I think your misinterpreting the intent here. If you specify a timestamp > with offset, it is fixed. That is what you say. And I am pointing out to international standard references. If you use offset as "fixed" it means such use would not be by standard, and you would confusing users and programmers who are using standard for calculations in programs. > It does not change with daylight savings or any other change in > rules for a time zone. It does not even specify a time zone. And while and before making that decision, did you review the standard that time zone offset is influenced and changed by daylight savings? It does not specify time zone. But it is derived from time zone, and is not same from time zone. Are you aware that time zone offset could have "skipped time" or "added time" due to daylight savings? That implies that by using time offset, you would forget daylight savings which are international standard, and make calculations wrong, because you started applying own standard in Org. 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. Read from: https://en.wikipedia.org/wiki/UTC_offset , | Daylight saving time | | Several regions of the world use daylight saving time (DST) and the | UTC offset during this season is typically obtained by adding one hour | to local standard time. Central European Time UTC+01:00 is replaced by | Central European Summer Time UTC+02:00, and Pacific Standard Time | UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00. ` Maybe you wish to include a new type of time representation, something like "Org time offset", in that case you are involving Org developers into even deeper problems, as then with the new type, you are left all alone to make that thing work. That new type of "fixed" time offset, would not be standard, and would confuse careful users and programmers. Example: - time offset would be PST UTC-08:00, for example 12:00 o'clock - with daylight saving time event (the time when people switch clocks), the offset of PST UTC-08:00, would suddenly become UTC-07:00, and the time offset would suddenly become 11:00 o'clock in that moment - now is your decision if you will keep counting 12 o'clock in Org, thus creating new type of time specific to Org or 11 o'clock as that is the international standard. Time offset will change with daylight savings, and must be thus derived from time zone. > While it is true that a specific location may have time zone changes > or that the offset from UTC might change as a result of daylight > savings, an offset specified in a times stamp does not change and is > fixed. This is one of the limitaiton with using offset. It is fixed only if you think is fixed when it is written once, and then you think it is fixed. In the sense of calculation of time, it is not fixed and for any calculation of time offset you need to observe in which time zone is that time offset, and if you do not know time zone you can't calculate it correctly. Please read Wikipedia article explaining it clearly. Please read how in China time offset is not every 15 degrees, and how there is wording "Although nominally" and "every 15 degrees". Time offset is thus calculated based on time zone and other factors. It is derived. It is not basic time type to be used for other calculations! It is a difference of time that is mostly in this way, but shaped by politics in other way. Time zone is time added or deducted from UTC. But not just added in mathematical sense, it is added by considering daylight savings, and time zones and politics. > I also think it is a mistake (which I've seen others suggest in this > thread) to equate an offset as being an abbreviation for a time > zone. That is very right. Time offset may be derived from time zone by using tz database, but it cannot just be automatically derived. Time offset is not derived from UTC, it is however, derived from tz database, observing time zones, politics. > For example, some have suggested things like +1 being the same > as AEST and both being abbreviations for Australia/Sydney outside of > daylight savings periods. I
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 by other text editors, and various applications, it is not feasible to expect that other editors and applications would be re-writing the displayed text to show to user their local time. Only user's local time is friendly to user. Other options may be added, though focus should be on helping human and making things easy. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 careful calling it constant as time offset is changing depending of daylight saving time. It is not constant. Time offset time stamp may be derived from time zone time. I am sure about this. Time zone time stamp cannot be unambiguously derived from time offset. I am mostly sure about this. > 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) > • This captures the idea of "when did it happen for the person who > made the observation" > • e.g., 2007-02-03T04:00:00.000+01:00 Offset is not that fixed, maybe from viewpoint of storage as maybe it is considered fixed in it's representation, but you have to keep in mind that time offset by it's definition is changing itself, suddenly, depending of daylight saving and time zone. I am trying to find well described reference to read, try here: Time Zones vs. Offsets – What's the Difference? Which Is Best?: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ , | Putting It All Together | | Given a time zone and a UTC time, you can know the offset—and | therefore the local time. 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). Given UTC and an offset, you | can know the local time. Given a time zone and an offset, you don’t | know much. That’s why a calendar systems work with time zones, | offsets, and UTC; we need the offset to go from local time to UTC, and | we need the time zone to go from UTC to local time. ` > • Instant with explicit offset and zone (fixed) > • e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago] > • Zoned local date time (floating) > • Tricky, requires decisions about how to interpret timestamps after > political changes. > • e.g., 2007-01-01T01:00:00.000[America/Chicago] For calendars it is good to follow recommendation Internet Calendaring and Schedulingn Core Object Specification (iCalendar) iCalendar - Date and time format: https://en.wikipedia.org/wiki/ICalendar#Date_and_time_format In other words it is good to follow what other successful applications are already doing. For example, if you open Evolution calendar in Gnome: evolution -c calendar and make task, and save that task as iCalendar, then you can see what time stamp format is used there for exchange purposes. Representation for user using Org file is different from representation for sharing purposes, as user already (mostly) have specified local time zone on this computer, while sharing object such as iCalendar file must take that information of local time zone and store it unambiguously. > I claim that before dealing with the nuances of calendar appointments, > repeating events, agenda displays etc, that Org must first support > fixed/absolute time instead of just floating time. Parameters needed to make it fixed are already in computer, only disconnected. changing this time stamp for Org: <2023-01-27 Fri 10:18> to something "fixed" would break Org compatibility for past Org files. While new unambigious time stamp formats may be introduced, the way to go is with past time stamps is to understand the time stamp for representation and calculation purposes by using OR logical function: timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-zone as by using those, for now still disconnected parameters, one can get the fixed time for representation purposes (Org export or sharing) or calculation purposes (on local computer and by using some shared Org objects). > Without some basis time scale the conversions from time zones and > offsets to some incremental time point is impossible. Resolving this > prerequisite will also simplify the timezone discussion because we > won't be mixing calendar issues with time issues. I guess that OR consideration above may remedy it and keep past compatibility while expanding more specific time stamp as option. > What would a roadmap be? > > • Design and implement an absolute and offset timestamp system > • Decide on a time scale > • Decide on a format and syntax > • Implement instant timestamps > • Implement offeset timestamps > • Design and implement the time zone aware calendar system This is a > separate project. Sounds complex to me and over board for program that tries to define data type by using simple text written ambiguously by many people. > What format and syntax should Org use? > > A heretical suggestion: We should abandon the day of week abbreviation > and use a new fo
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 > implementation? I have already previously mentioned about it. In my opinion, features such as opening specific function on URI scheme shall be unified in Emacs. Org should now hard code new way of opening URL schemes, but use Emacs settings. And I am aware that it is late for such decision, historical decision was individual based, when Org was not part of Emacs, and it will break compatibility but then you could introduce option for people to start changing slowly and integrating better with whole system. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: This is out of thread subject
* 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 security risk. > > Well... > https://bugzilla.mozilla.org/show_bug.cgi?id=1678994 That is fine, it is useful to be asked by which application something will be opened. It is question about permission, which is given once. That does not prevent user opening any URL with external programs. Or content type. There is more in computing than single user need. An HTML file on local area network may list various URLs to various people of single organization, and their work disconnected from Internet -- where all users can access any kind of files, it need not be single user need. > https://bugzilla.mozilla.org/show_bug.cgi?id=1565574 Any hyperlinks executing external program should not be opened automatically of course. Imagine placing 20 various programs as hyperlinks where user by opening single page launches 20 programs, that is out of control of user. Having option for user to decide to allow it, would be fine.. Otherwise hyperlinks like mid: should not be opened automatically, hyperlink should wait for user to activate it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 specific E-Mail. kde-pim does not offer an easy way to > extract that or the message-ID. How many Maildirs do you have? and what does program: akonadi_maildir_resource does? Should it find e-mail? Without Akonadi: Solution may be simple without akonadi and external software. It would be to provide main Maildir, then for program to find submaildirs, and to find Message ID in every e-mail, and record it, once per day, of course with e-mail file or folder location plus Message ID. This is simple program and can be done in shell or Emacs Lisp, collecting all Message IDs efficiently from every Maildir. This program thus can be universal program, and then function can decide how to open e-mail, and it is just fine opening e-mail in Emacs as well. Same program could be used to find e-mails by name or sender, or recipient. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Should Org provide commonly used link types?
* 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 instead. Max pointed to experimental proof-of-concept code for pdf
> + page in another email.
Yes, you could extend file: and make special handlings for various types.
> > Message-ID, should support FOLDER+Message-ID
>
> I am not sure here. How can we utilize FOLDER? It depend on the kind of
> external application or Emacs package we use to open the link.
If you only provide "mid" and function for user to customize it, that
is enough, then user's function must know how to handle it.
However, that is not by standard as "mid:" is not meant to be
referable from Org. See: https://www.rfc-editor.org/rfc/rfc2392
That URL expects message-id only, with possible content-id
mid-url = "mid" ":" message-id [ "/" content-id ]
Which means, in turn, that "mid:" shall be reserved only for indexing
programs, as RFC mentions "indexed", and I assume that is what was
meant with it.
Many e-mail clients do not have general indexing of e-mails and yet
they internally use Message IDs and have no problems finding it, or
may have internal indexing not exposed to user.
I do think that my proposal is more flexible, by allowing user to
introduce function, user can go away from standard and introduce
folder, in the sense:
mid:/home/user/Maildir?1231...@gnu.org
with parts being:
mid : /home/user/Maildir ? 1231...@gnu.org
I have many many mbox files on computer, they are used by various
programs, there is no single program opening all of mbox-es, and
Maildirs, and I have 59869+ Maildirs in total.
In case I as user change e-mail client to some indexing one, my
function can still discard the file location part and find Message ID
Another idea is to use "file:" as usual, for those e-mail Message IDs
which are stored in files, in that case function again must be
somewhere to detect:
- if file is Maildir, mbox
- to use Page ID part of "file:" if such exist, as Message-ID
or third, new URI scheme can be introduced, such as "message-id:"
which supports file and message ID together.
Outside of scope of thread:
---
Personally I have it solved with hyperlinks on higher level, they
remain immutable inside of Org, while decision making how to open them
is decided in their definition.
[[elisp:(hyperscope-action 1)][📝 ╔ Notes]]
[[elisp:(hyperscope 73361)][Secondary School in Lobolwala]]
And there is even more general UUID based hyperlink:
[[elisp:(uuid "6ADD037A-31BC-435A-BEC8-FE990EBF2A17")][Secondary School in
Lobolwala]]
UUID based hyperlinks avoid hard coding hyperlink, and avoid hard
coding the action to run hyperlink.
Actions for UUID are then defined by user. When capturing UUID
hyperlink, name is captured as well to construct Org hyperlink.
(defcustom rcd-db-uuid-action-alist '(("people" . cf-people-by-id)
("hyobjects" . hyperscope)
("sobjects" . ignore)
("predicates" . ignore)
("uuid2uuid" . ignore)
("properties" .
rcd-notes-properties-list-by-referenced-uuid)
("statsdefinitions" .
rcd-r-statistics-view)
("transactions" .
rcd-accounts-transaction-edit)
("messages" . rcd-message-edit))
"Database UUID action alist."
:group 'rcd
:type '(alist))
That way using abstract UUID hyperlinks enables more flexibility,
practically more collaboration and accessibility to hyperlinks, as it
does not "hard code" the object named "Joe Doe", as that object may go
across computers. "Joe Doe" vCard may be opened on computer A, if such
has been received, because it has same UUID inside, while on computer
B, database entry is opened locally for that UUID, but on computer C,
remote database entry is accessed.
> > Geo location shall be supported, as it has already many handlers in
> > GNU/Linux, then GPX files, GeoJSON files
>
> Are there any? I only know web handlers. I did search at some point.
When you use geographic software, the /usr/share/applications get
populated with various handlers, for example:
-rw-r--r-- 1 1.2K Jan 11 20:53 marble_geo.desktop
with Exec=marble --geo-uri=%u
Yes, there are many web based handlers.
In Emacs there is `osm' package that can easily use Openstreetmaps as
URI handler for "geo:"
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: Should Org provide commonly used link types?
* 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 this horror: > > (info "(org) Adding Hyperlink Types") > > that leads nowhere. Forget about "usability". > > I am sorry, but what can be simpler than > > (org-link-set-parameters "man" :follow #'org-man-open) Customize is simpler, it was made to help users, that is what we have in Emacs: Hyperlink URI scheme: man Function: org-man-open -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
This is out of thread subject
* 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 > > implement proper URL detection, not asking its users "to give it some > > hints" and using "a kind of heuristics". A string either is a valid URL > > per the relevant RFCs or it is not. > > You probably decided that I was writing about > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774 > [WISH]: Let us make EWW browse WWW Org files correctly > > That is from my point of view is an excellent example how to bury a valid > feature request "allow me to do" by aggressive demand "it must be by > default" disregarding unresolved security issues and by adding more noise by > discussion of unrelated stuff (should Org files have text/... or > application/... mime type). > > Back to the topic, URI handling packages have incompatible features. It is > the reason why users have to had explicit configuration. I can't follow or understand you in everything above. Purpose of community discussions is to yield with something productive. Whatever I said in the first notion does not need to be so, and I really don't mind when I see that discussion deviated from the point. I am not Don Quixote to fight mills for browser that few people use and have decision making. EWW still cannot support customizable content/types but I also do not find it hard to bypass it's functions. At least there was "useful" (by irony) decision that "opening Org files in Emacs is security risk" -- one big fricking LOL on that. Emacs itself is security risk, as it is programming language and security is measured by weakest chain. 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 security risk. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Should Org provide commonly used link types?
* 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. > They are: mailto, news, nntp, snwes, afp, data, disk, disks, hcp, htp, > htps, http, iehistory, ierss, ile, javascript, le, mk, moz-icon, > ms-help, ms-msdt, ps, res, search, search-ms, shell, tps, ttp, ttps, > vbscript, vnd.ms.radio, and file. It is not relevant what Firefox support or not, as it is user customizable option. > Note that mid: is not listed. User can set it. > 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 this horror: (info "(org) Adding Hyperlink Types") that leads nowhere. Forget about "usability". Customize interface is much better. How about this in customize? - prefix: pdf - format %s&%s - function to run: open-pdf However, how it was programmed in Org in such demanding and boring way. No wonder people complain for simple PDF opening by page number. I am changing my mind, now I really think that it is better you hard code those hyperlinks in Org as you said, that way you will get functionality that users can still choose but need not be bothered by programming. 1. For PDF there are not many PDF viewers that support opening by page number or query, so you could hard code it all. XPDF is so far best as it supports capturing in easy manner. 2. For mpv, vlc, you can open video and audio hyperlinks at specific place. I am using `mpv' package to capture video at exact point like this: (defun hyperscope-capture-mpv-playback-position () (interactive) (cond ((mpv-live-p) (mpv-pause) (let ((time (mpv-get-playback-position)) ;; subtype? (name (rcd-ask-get "Name video position: "))) (cond (time (hyperscope-add-generic name hyperscope-mpv-played-video nil 3 nil 1 time)) (t (rcd-warning-message "Could not get time for video play" (mpv-pause)) (t (rcd-warning-message "mpv not running" which is very easy to convert to Org. Package `mpv' already supports Org type Hyperlinks. Summary for now, PDF, video, audio, plus all at exact location. What about EPUB, DJVU, MOBI? - mupdf supports opening EPUB at specific page - zathura will surely work with DJVU to open at specific page Summary: PDF, EPUB, DJVU, video, audio, plus all at exact location. I am using general "media" which can be either audio, or video, could be PDF or something else. Message-ID, should support FOLDER+Message-ID Is it possible to support Emacs bookmarks as hyperlinks? I would include that. xournalapp is software that I use, and RMS uses too I heard, it is excellent for PDF editing. It has its own format and can open up also by page number. Geo location shall be supported, as it has already many handlers in GNU/Linux, then GPX files, GeoJSON files I have playlists as hyperlink, and other 100 different examples which I do not consider immediately useful for Org. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)
* 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 more concretely what kind of "support" > > > this is? > > > You can find interactive support in `sql' library, functions such as: > > > M-x sql-oracle > > > which supports proprietary Oracle Database: > > This raises two questions. > > 1. For this purpose, what kind of thing is "the Oracle Database"? > a. A library to link with? > b. A program to run in a subprocess? It is program that runs in a subprocess. > c. A server running SaaSS? Theoretically it could be as access may be network based. But according to my knowledge this product is proprietary and may be downloaded and run on users' computer or network computers. > 2. How does Emacs communicate with that thing? > a. By function calls within a process? Yes. > b. Via shared memory? > c. Via a pty or pipe? > d. Via sockets? By invoking proprietary program named "sqlplus" which function is defined in library "sql.el" and by using comint-mode (defcustom sql-oracle-program "sqlplus" "Command to start sqlplus by Oracle. Starts `sql-interactive-mode' after doing some setup. On Windows, \"sqlplus\" usually starts the sqlplus \"GUI\". In order to start the sqlplus console, use \"plus33\" or something similar. You will find the file in your Orant\\bin directory." :type 'file) (comint-mode) Major mode for interacting with an inferior interpreter. Interpreter name is same as buffer name, sans the asterisks. Return at end of buffer sends line as input. Return not at end copies rest of line to end and sends it. Setting variable ‘comint-eol-on-send’ means jump to the end of the line before submitting new input. This mode is customized to create major modes such as Inferior Lisp mode, Shell mode, etc. This can be done by setting the hoo In my opinion Emacs should not be invoking proprietary programs, and distributing sql.el with Emacs opposes the principle of not recommending proprietary software. By having functions to run proprietary software from within Emacs we are advertising proprietary software. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Org mode links: Open a PDF file at a given page and highlight a given string
* 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 percentage")][small percentage]] (defun rcd-okular (file &optional page query-string) "Open `okular' on PDF FILE. PAGE is optional page number QUERY-STRING will be eventually found highlighted." (let* ((okular (executable-find "okular")) (args (list file)) (args (if page (append (list "-p" (format "%s" page)) args) args)) (args (if query-string (append (list "--find" query-string) args) args)) (name "*Okular*") (buffer (generate-new-buffer-name name))) (cond (okular (apply #'start-process name buffer okular args)) (t (user-error "Program `okular' not found") -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
* 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 > > where I don't care about the local time where the record was generated, > > but with when it occurred in relation to other log recores. > > I agree that it is more convenient to have uniform offset in such case, > especially in the case of multiple files having their specific timezone. > During trips I do not expect so much changes of timezone to make comparison > of timestamps significantly harder. > > > I would argue that all depends on how you use the information. My org > > files are consumed by me (reading) and by scripts, elisp and other > > programs. > > For scripts given offset should not be an issue at all. And it is up to you > if you prefer to have UTC instead of local time offset in you files. Surely I understand your point of view, but offset does not provide to people their local time, that would just make confusion. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
* 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 as 11 hours ahead of local time. Nevertheless, Org is certainly > > free to interpret it as relative to UTC. > > My primary concern is that I might be wrong assuming that format like > [2023-01-22 Sun 08:29@+1100] with offset in respect to UTC is reciprocal > identity mapping to UTC. ISO 8601 is international standard on which you should make decisions. https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC https://en.wikipedia.org/wiki/UTC_offset , | The UTC offset (or time offset) is an amount of time subtracted from | or added to Coordinated Universal Time (UTC) time to specify the local | solar time (which may not be the current civil time, whether it is | standard time or daylight saving time). ` I hope your concern clarifies itself. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 than arbitrary ideas not known to anyone, even > if they sound better for some users. Not that I can agree as heavy user of e-mails. mid: -- shall support IMAP, mbox, Maildir, file location in first place. Please think of 1998, that is year where majority of people used mbox, which meaning was that all e-mails were (mostly) in single file. And even with that single file, users were to open that file to request "mid". This implies that e-mail program had to know which file to open. That is missing argument to that proposed standard, practically no standard at all, laughable to say it is "standard". mu, notmuch and Thunderbird all use index to search for Message-ID, including online web clients. But location is missing part as on user's computer there may be too many mbox, Maildir files, mh, what else, and messages may be on IMAP server. I cannot provide to myself "mid:" hyperlink without providing location of Maildir file, if I am to use Mutt as e-mail client or any e-mail program that does not have indexing built-in. I have to specify file plus Message-ID. That would mean something like mid:///home/data1/protected/Maildir/yanta...@posteo.net&87mtz84om9.fsf@localhost because yanta...@posteo.net would be either mbox, Maildir or other format. I don't care for useless and never adopted standards from 1998. It is 2023. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 > > decades. > > Well. The more widely used standard is Maildir - downloading emails from > server to local machine. Emails are just files there that can be indexed > by variety of mail client software. I have to give some corrections according to my knowledge. Maildir is less used format, not widely used. Not even in GNU/Linux, it is simply not default. I guess mbox format is much more used. https://en.wikipedia.org/wiki/Mbox And it is not related to how people download or not download e-mails. And how server uses mail boxes is also independent of how users use mailboxes. E-mails are not "just files", they are pieces of informaton and if they are stored as files depends of software. When e-mail is on server, it may run different software storing e-mails in the databases where database objects are not independent files for each e-mail, and can't be manipulated as such. And retrieving e-mails, while mostly in form of files, may be also in form of a database objects. There is server side and client side software, they work independent of each other and decide how to store e-mails. Or not store it at all at client's computer. To understand what is widely used e-mail file format, one has to see what are widely used e-mail clients. Maybe this picture may help: https://d27jswm5an3efw.cloudfront.net/app/uploads/2021/04/most-popular-email-clients-graph.jpeg or this one: https://www.oberlo.com/media/1673256706-most-used-email-clients-worldwide.png?fit=max&fm=webp&w=1800 Those are by majority all web software clients. No matter if statistics are right or wrong, not even Thunderbird is there, and Thunderbird has Maildir only as experimental option. And regarding indexing, many e-mail programs do not support indexing, it is not at all their main purpose. They may retrieve e-mail, read, reply, sort, delete, but indexing is often forgotten feature. > The main question is which email clients actually support mid: links. > notmuch does, but in non-standard way, without doing it system-wide. notmuch is more indexing system, and programs working with notmuch may be considered email clients. Another e-mail indexing program is "mu" and I am sure it can search by Message-ID: https://www.djcbsoftware.nl/code/mu/ as notmuch never worked on my computer. I can't verify it as I did not use index, being very efficient without it due to method of sorting all e-mails per Maildir representing the e-mail address. Sadly mid: appear not to be supported by many software, just as many software not supporting various URLs when they should. Let us not forget there are universal URL launchers, such as: - exo-open from XFce - xdg-open - opens a file or URL in the user's preferred application (Free Desktop - kde-open from KDE - rox -U -- may launch any type of URI handlers by user customization: https://rox.sourceforge.net/desktop/book/export/html/163.html And there are others, including browsers being mainly used to launch any types of URI schemes. Maybe you can see the pattern that there various launchers for URI schemes and all of them allow users to specify which software to use, and there are many browsers, majority of browsers follow the pattern to allow users to specify how to open which URI scheme. By seeing the pattern, you may see why is it useful. I hope so. And then I hope you will not keep URI handlers hard coded, but allow Org users to decide which launcher, browser, or what to use on Org hyperlinks. When I think of "mid:" I think of "Message-ID: " and that is generally not hard to find in various e-mail formats. In Emacs, for mbox files, it would be something as: (search-forward "87y2e2bgzh@example.com") followed by extracting and displaying of the found e-mail. With Maildirs it would be `grep' search on Maildir folder, it is almost instant on hundreds of e-mails. Of course scalability is a problem when using `grep' as with too many e-mails, it would last long. That is why both for mh, mbox, Maildir and other folders, one shall always specify the folder location. Without folder location mid:123 alone would require indexer to find the Message-ID. That is why it would not be for Org to specify how mid links are opened but for user to customize it. As user may have mid:// format or only mid: or maybe mid://file/message-id format, depending of the software. That Thunderbird uses only mid:message-id format is definitely unique and not ordinary as generally e-mail clients do not support it. Additionally, mid: need not specify only local file, it could specify IMAP as well mid:imaps://example.com/INBOX&message-id -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/cam
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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. > > It reminds be complains by some person that Org must be able to recognize > any URL in free-form plain text just because there is a RFC describing > format of URL. That person did not really propose to Org to do it, but to have Emacs EWW to be customizable, so that any content type could be opened by user's settings. You missed the point of it. > Try to think from position of a developer. >From position of developer, developers shall ideally think of users, and users think of the assistance of computer to users. Users appreciate developers who make their life easier. > An entry may be added to `browse-url-handlers' after loading of ol. > > org-link and browse-url are so flexible that it would be hard to reliably > match their entries taking into account different set of supported features. > The former allows e.g. fuzzy search links, the latter something similar to > Android deep links. That means Org authors missed to use Emacs built-ins. > I have no idea which way you configured mid: links in Org, but this thread > contains 5 lines that successfully works for me. When goto-mode works with mid: by me setting up browse-url-handlers, then I have expected Org to work as well. But I do not rely on Org mode to use browse-url, rather I rely on Org using elisp: links. That is not really "mid:" but it will work for long time and be independent of Org developers' decisions. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 Org will be using Emacs settings, but it follows
it's own settings.
I mean these settings:
browse-url-handlers is a variable defined in ‘browse-url.el’.
Its value is
(("gemini:" . elpher-go)
("gopher:" . elpher-handler-go)
("about:" . hyperscope-about)
("mid:" . my-handler)
("hyperscope:" . hyperscope-url)
("e2dk://" . amule-handler))
Original value was nil
An alist with elements of the form (REGEXP-OR-PREDICATE . HANDLER).
Each REGEXP-OR-PREDICATE is matched against the URL to be opened
in turn and the first match’s HANDLER is invoked with the URL.
A HANDLER must be a function with the same arguments as
‘browse-url’.
If no REGEXP-OR-PREDICATE matches, the same procedure is
performed with the value of ‘browse-url-default-handlers’. If
there is also no match, the URL is opened using the value of
‘browse-url-browser-function’.
This variable was introduced, or its default value was changed, in
version 28.1 of Emacs.
You can customize this variable.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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:" links by default, > but I am still considering `browse-url' as the proper handler. You should neither enable, neither disable opening of any links on the Org level except maybe Emacs Lisp links. Otherwise let users enable or disable what they want. > Code to determine handler is platform-specific, e.g. for Linux > > xdg-mime query default x-scheme-handler/mid > xdg-settings get default-url-scheme-handler mid > > The latter actually calls the former. I would avoid both variants during > load time. > > If you get browser fallback then you are advanced enough user to avoid a DE. > Gnome shows application selection dialog, KDE throws an error > window. Let users open Hyperlinks with any browser or function how they want. I am aware that Org has that mixed hyperlink types as explained in: (info "(org) External Links") and when I say "mixed" it does not support the expected standard of URI Schemes (https://en.wikipedia.org/wiki/List_of_URI_schemes) as it introduces various Org related hyperlinks. At this point, after so many years, nobody recognizes that such capricious single user decision does not scale well for broad public. And now because all the users are entangled using non-standard URI schemes, it is very hard to switch, as it would break compatibility. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 package to open some > > types of links. It allows to have the same handler for all Emacs > > packages. I do not think that Org-specific handler would be better. > > 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. Thanks. It does not mean that browse-url "will not work" but that user did not customize content types. You need not think what users will customize neither you can't know what future brings. Do you see that any browser could have the same strategy to maybe forbid various URLs, but browsers mostly adopted the strategy to let user customize how to open some URL. >From Org side that is all, you do not hard code how to open various links, but there shall be customization for users to decide how to open content types. That is what other browsers do as well. You don't need to think of it, as you cannot control other program from Org. Please allow users to set URL handlers how they want. That is customary for decades. Other program must know how to handle hyperlinks, if to report error, or to warn user or to ask user how to open such URLs. For example Elinks with $ elinks mid:123 "This URL contains a protocol not yet known by ELinks. You can configure an external handler for it through the options system." or for example Firefox: "Firefox doesn’t know how to open this address, because one of the following protocols (mid) isn’t associated with any program or is not allowed in this context. You might need to install other software to open this address." It is for me as user to set it, and not for Org to think how user is to customize or use other software. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 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. To circumvent hard coding in Org, one can always use elisp: type of links: (defun my-handler (mid) (message mid)) [[elisp:(my-handler "I am ok here")][my handler]] Though it is not logical to hard code in Org how this or that URL can't be open, as Org should allow present configuration of user to run. Is that currentlyy working? > Configuring of "mid:" links requires just a few lines in init.el and they > are quite usual for custom links. I have configured it, it does not work in Org -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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
> > > E-Mail
> > > and need an efficient way to come back from the TODO to its origin?
> >
> > It is not up to Org. Try
> >
> > (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
> >
> > You will likely see nothing.
>
> Well, M-x (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
> produces [No match].
By default no match, but as already said, that depends of your
settings.
It works on my side as I have settings for that.
In Emacs it is up to user to set how to open it.
Same as with any Internet browser, when you try to use less used URLs,
then you will see browser is asking you by which application to open
it, if to remember that application and so on.
For example magnet: could be opened by Deluge or other torrent
applications, depending of user settings in browser.
There are too many applications and hard coding how to open message ID
would be limitation, not feature.
You may cutomize variable `browse-url-handlers' to get what you wish.
Its value is
(("gemini:" . elpher-go)
("gopher:" . elpher-handler-go)
("about:" . hyperscope-about)
("hyperscope:" . hyperscope-url)
("e2dk://" . amule-handler))
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 from e-mail to keep it as evidence, and references to document in the e-mail are useful. It seem as a "forgotten" and lacking feauture in many software. From: TECHNOLOGY TEMPLATE PROJECT OHS Framework : https://www.dougengelbart.org/content/view/110/460/ Dynamic knowledge capture, integration, management Automated capture, indexing and cross-referencing, integrated email, journal/library, intelligence collections; utilities for repository management Sadly software designers do not follow successful principles, they tend to follow personal or individual demands, and we get some use of it, though we could do so much more for people. - automated capture is missing in many software programs, as programs are tool centric, made to be "better" among competition, instead of integrating with competition. Example is Evince PDF viewer which does not have capture system. At least it has referencing system by page and query. While XPdf program has possibility to capture and reference in the same time. Many PDF viewers don't have system to capture page number, query, some have annotations usable only from inside of the tool, without providing integration to other applications. So it is with E-mail clients, they tend to be self-centric, not providing information in usable way to other applications. Would they do, there would be no such external tools like `mu' and `notmuch` for indexing, as any information would be already indexed and re-usable by other software (competition). In Emacs we have that option to remember position of a cursor in some specific file by customizing `save-place' option. That is miniscule example of automatic capture of piece of information such as location of a cursor, and with automatic referencing to that piece of information so that user get to that portion of the file or text where user was in last session. I think it should be by default. And so many text editors do not have that basic feature. It is good to keep filing feature requests to various software authors that they start implementing note capturing features. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)
* 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 which supports proprietary Oracle Database: https://en.wikipedia.org/wiki/Oracle_Database or M-x sql-ms which description says: sql-ms is an autoloaded interactive byte-compiled Lisp function in ‘sql.el’. (sql-ms &optional BUFFER) Run osql by Microsoft as an inferior process. > Which GNU package supports them, and how? Emacs, sql package > Are they nonfree programs, or are they SaaSS? They are proprietary programs that may be also SaaSS. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
* 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 Australia/Sydney timezone > refers to a region of space/time whose relation to absolute time is fixed > for any moment, but potentially variable over time. 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. That is assumption by poster. I do not find it easier. As when user sees 08:29 that user will think of time in Berlin, of time which is not in UTC, and not time in UTC plus 11 hours. What is easier is what is generally accepted in any type of software worldwide, just represent it in local time zone. Difference between offset time and time with time zone is that time zone includes rules of daylight savings and other anomalies. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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 `browse-url-default-handlers` or
`thing-at-point-uri-schemes', that way you need not need to hard code
it in Org, let it be handled on Emacs level.
Hide browse-url-handlers:
'(("gemini:" . elpher-go)
("gopher:" . elpher-handler-go)
("about:" . hyperscope-about)
("mid:" . mutt-by-message-id)
("hyperscope:" . hyperscope-go)
("e2dk://" . amule-handler))
Unless it already works that way.
But on my side it opens up GUI widget telling me "No match, create
heading" -- which is wrong.
If I however, turn on M-x goto-address-mode then about:hyperscope and
mid:123 starts working automatically, it is handled by user's choice.
List of URI Schemes:
https://en.wikipedia.org/wiki/List_of_URI_schemes
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Re: Link from orgmode file to E-Mail (using kmail or notmuch)
* 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://
> orgmode.org/manual/External-Links.html
I am using Mutt: https://mutt.org which must be in your
distribution.
There is way how to automatically capture Message-ID and put it
outside of the Mutt, though I did not yet implement it.
However, if I wish to open specific e-mail I point to the Maildir, or
maybe Mbox or other type,
Maildir: /home/data1/protected/Maildir/to...@tuxteam.de
Message-ID: Y0mt4/g+dlklu...@tuxteam.de
Then I use this function:
(defun hyperscope-mutt-view-by-message-id (link argument)
"Opens email by message ID by using mutt"
(let* ((folder link)
(message-id (replace-regexp-in-string "=" "=" argument))
(push (format "push '=i %s'" message-id)))
(call-process "xterm" nil nil nil "-e" "mutt" "-f" folder "-e" push)))
Where by function must receive LINK and ARGUMENT, whereby ARGUMENT
means Message-ID string.
xterm is called, mutt launched for FOLDER which is same as LINK, and
"-e" specify a command to be executed after initialization, which is
in this case "push "'=i Y0mt4/g+dlklu...@tuxteam.de'"
And I get to see that specific e-mail that was hyperlinked.
You may implement this in org by creating elisp: type of links easy. You could
call this function different:
(defalias 'my-message-id 'hyperscope-mutt-view-by-message-id)
(my-message-id LINK ARGUMENT)
Opens email by message ID by using mutt
[[elisp:(my-message-id "/home/data1/protected/Maildir/to...@tuxteam.de"
"Y0mt4/g+dlklu...@tuxteam.de")][Link to my message]]
And after clicking on the above Org hyperlink I can see it works well.
KMail does not work on my side, so you can see which command line
options are available to find message by Message-ID.
In Thunderbird you may use this plugin:
Copy Message ID :: Add-ons for Thunderbird:
https://addons.thunderbird.net/en-us/thunderbird/addon/copy-message-id/
as to get quickly Message-ID.
The way to open up in Thunderbird is:
./thunderbird mid:PUT-HERE-YOUR-MESSAGE-ID
Here is easier way to insert Message-ID hyperlinks:
(defun rcd-org-link-message-id-by-elisp ()
(interactive)
(let* ((my-selection (gui-selection-value))
(functions '("(my-message-id \"%s\" \"%s\")"
"(message-id-by-thunderbird \"%s\")"))
(function (completing-read "Choose function for Message-ID: "
functions nil t))
(name (read-string "Name of link: "))
(folder (read-string "Enter mail folder if any or RET for nothing: "))
(message-id (read-string "Enter Message-ID: " my-selection)))
(insert "[[elisp:" (format function folder message-id) "][" name "]]")))
1. Copy Message ID in memory, but you also need to know Mail folder, depending
of function
2. M-x rcd-org-link-message-id-by-elisp and answer questions
3. [[elisp:(my-message-id "my mail folder" "my message ID")][my name]]
> I'm on Linux, KDE as GUI, distro Tumbleweed by openSUSE. The E-mail
> software is kmail. Unfortunately, there is no way to get the path to
> an individual E- mail out of kmail, which I could simply use to put
> it into my orgmode file as a link. So I installed notmuchmail and
> the emacs package notmuch.el.
It requires indexing and wastes time. If you use Mutt, it will open up
Message-ID e-mails in breeze. You may invoke external HTML viewers or
external program to see e-mails in different way. I know it is double
work.
Peculiar ways to make Evolution work are explained by Karl Voit:
Moving from Thunderbird to Evolution for Emails and Calendar:
https://karl-voit.at/2021/06/01/Thunderbird-to-Evolution/
Feature request: getting a message-id link from email + CLI option to open
email via message-id (#1508) · Issues · GNOME / evolution · GitLab:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1508
> By notmuch-search I can find an individual E-mail. In the E-Mail
> buffer I type c I , which copies the message-ID of that E-Mail into
> the keyring. Instead of a link I paste the message-ID into my
> orgmode file. If I'd like to read the E-Mail again, I can use
> notmuch-search: id: to find the E- Mail again. I know,
> this is not a really efficient way. Probably you are not surprised
> to read my question: How can I have a link in an orgmode file to an
> E-Mail using either a feature of kmail oder notmuch ? Regards,
We tried to solve this problem for Mutt here, since 3 years already:
Feature proposal: provide possibility to link directly to a message (#172) ·
Issues · Mutt Project / mutt · GitLab:
https://gitlab.com/muttmua/mutt/-/issues/172
Of course, one can see that both in Gnome and Mutt society, people
hardly understand use cases of capturing hyperlinks to messages.
Capturing of e-mails attributes is more of a problem that creating
hyperlinks in Or
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 > > > report both UTC and local time. User will be able quickly to > > > determine if > > > local time is incorrect for some reason, such as DST or travel. > > > > Other way around, it has to translate time stamp into UTC time in the > > first place. > > Yes, to store the time stamp, Org must take it from the event time of the > user and translate it to UTC. When reporting an occurrence to the user, > then Org must translate from UTC to the user's space/time. User might have > a toggle, like pretty entities, that either shows UTC or translation to > user's space/time. That is right. I have stated same. How do you want Org to know that user's time is in X time zone? It means, that new settings, variables, functions, must be introduced to handle it properly. Timestamp like this one: <2023-01-21 Sat 09:55> at HTML export will be from 95% and upwards incorrect. To be correct, time zone designation shall be placed in HTML export. User could be in South America, not in London, that exports it. Time zone UTC does not apply for South America. Representation is wrong. When you say that Org must take it from the event time of the user, that means that Org must take some parameter to understand what time zone user was. That means involving functions for export, or sharing of Org files. In general, we speak about representation. You may start making distinctions between "events" and "occurences", but technically we speak of time stamps which lack relation to time zone in Org. Whatever you "time stamp" without time zone, representation of it in other time zone becomes difficult, as it lacks the fundamental designation of time zone where it was recorded. And it does not matter if user records time zones in UTC, or other time zones. What matters is designation of time zone. Parameter must exist, something like "#+TIMEZONE: PST" As that property is then used by programs to understand time zone of the file, or task. In general computers store things in UTC. We are repeatedly discussing what is already agreed before decades. What we need in Org is representation in time zones. All programs work by storing in UTC time zone: -- Observe file system: $ touch MY-FILE ~ $ ls -l |grep MY-FILE -rw-r--r-- 1 admin input 0 Jan 21 16:21 MY-FILE ~ $ TZ=UTC ls -l |grep MY-FILE -rw-r--r-- 1 admin input 0 Jan 21 13:21 MY-FILE UTC is basis for time. There are time zone libraries and calculations. All that one has to think for Org is representation in familiar local time zone. > > Expecting that all user among so many various time zones write their > > time stamps in UTC is not reasonable. Org users are advanced, I know, > > but majority of note takers with other applications will not even > > think of different time zones, it is surprise they get when dealing > > internationally. People are not ready for calculating or even viewing > > their own time in UTC time zone, unless they are English or Icelandic, > > Portuguese, or Africans in parts of the West Africa. > > > Org should translate from the user's space/time to absolute time, UTC. That is right. So far I am telling same, maybe we think is not. > The user has to tell Org what is the space/time relationship to > absolute time. That is right. I said that long ago. The way to "tell it to Org" is at export, for Org to recognize it in terms of Lisp (or time-stamp-zone heading-time-zone file-time-zone system-time-zone) whatever comes first, then at any sharing of Org directly to people in other time zones, and in other uses cases. Such sharing and export must have variables that help to interpolate time properly in other zones, and Org shall recognize that time stamp displayed is not in local time zone and ask user if to show or translate time stamps. Many options exist. Best is when it is automatic, as that is usual in many other software. > Org might use the timezone machinery to suggest a space/time > relationship to absolute time, and it might warn the user when the > user's suggested relationship differs from the value reported by the > timezone machinery. That is right. > > > Storing timestamps in UTC solves the interval problem Ihor > > > raised. Intervals always make sense in absolute time. Moving them > > > to event time leads to the insanity Ihor mentioned. > > > > The other way around. Assuming that time stamps are UTC raises > > problems for all other people: > > https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png > > > > Org now does not support time stamps, right? > > > > So people write timestamps in their own time zone! Is it right? > > IIUC, Org currently sto
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 and event as opposed to distinction by its ordinary meaning in English. What really matters --- What matters is aid to users' life. When arguing, try to make a checklist and TEST it: - [ ] can user easily understand the time displayed? - [ ] can user relate the displayed time to his local time without hesitation? - [ ] is that program that programmer creates beneficial to user or to programmer, or theoretician of absolutes, rights and wrongs? How to test it? Usability Testing 101: https://www.nngroup.com/articles/usability-testing-101/ Today there is in computing pretty much agreement that: --- - All computer time should be stored to UTC, UTC being basis for any other computations - System libraries have (or should have) various configurations - Computer users should be shown their local time * Overview of noun occurrence - The noun occurrence has 2 senses (first 2 from tagged texts) 1. (29) happening, occurrence, occurrent, natural event -- (an event that happens) 2. (3) occurrence -- (an instance of something occurring; "a disease of frequent occurrence"; "the occurrence (or presence) of life on other planets") * Overview of noun event The noun event has 4 senses (first 2 from tagged texts) 1. (62) event -- (something that happens at a given place and time) 2. (6) event, case -- (a special set of circumstances; "in that event, the first possibility is excluded"; "it may rain in which case the picnic will be canceled") 3. event -- (a phenomenon located at a single point in space-time; the fundamental observational entity in relativity theory) 4. consequence, effect, outcome, result, event, issue, upshot -- (a phenomenon that follows and is caused by some previous phenomenon; "the magnetic effect was greater when the rod was lengthwise"; "his decision had depressing consequences for business"; "he acted very wise after the event") -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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-location-name (setq calendar-latitude (setq calendar-longitude (setq calendar-standard-time-zone-name (setq calendar-time-zone -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 local timezone > changes due to daylight savings time and the fact you have two different > requirements I do not use Org for time stamps. I am using PostgreSQL. My time stamps show correctly (hopefully) as I rely on the design of that software. I may be very wrong. Though as user I want simple thing, to record time, and that time has to be displayed in my time zone, and I want to have functions which will provide for example accounting statement in the time zone of the recipient in Washington, USA. As simple as that. There is no need for Org to deal with daylight savings, as UTC underlying functions are expected to deal with it. Time zone database, C library, I cannot know. But any error there shall go to system maker. Developing such complexity on Org level is not necessary. For Emacs it makes fun to have various calendars, but for international time, that has to be handled by system libraries. > 1. For meeting where all people are in the same timezone, a transition > in/out of daylight savings changes nothing. The meeting time stays the same > > 2. For meetings wiht people from different time zones, when daylight > savings transition occurs, the timestamp needs to be changed. Nothing > needs to happen for the people in other time zones - it isn't their > problem and their meeting time is not affected. Sure, but that is not calculation for higher level like Org, it is for lower level, like system library. Discussion shall be given to developers of GNU C library to solve calculations with daylight savings. If such functions do not exist, then they can be made. > Ihor['s suggested solution was to just use the TZ of the 'meeting', but > that is ambiguous. A meeting doesn't have a time zone and picking just > one of the recipients doens't help as now you just have the issues of > their daylight savings transitions etc. ☺️ A meeting can have time zone. My friend, that is exactly how we do meetings, I have even given examples from my life on meeting scheduling on this mailing list. We say "Greek time 9 o'clock AM" -- and we meet and talk to each other. If there is any daylight saving, so? My computer will think about it. Not me. I have alarm that counts down, I must rely on my devices. See: System time and hardware clock https://www.suse.com/support/kb/doc/?id=16358 > The Linux kernel maintains a system time. This time is initialized at boot > time using the hardware clock(also known as real time clock, RTC, BIOS clock > or CMOS clock). As the hardware clock does not provide information as to > whether it is kept in UTC or in local time, this needs to be configured > explicitly, in YaST -> System -> /etc/sysconfig Editor -> System -> > Environment -> Clock -> HWCLOCK. > Linux changing to and from DST > Linux will change to and from DST when the HWCLOCK setting is set to `-u', > i.e. when the hardware clock is set to UTC (which is closely related to GMT), > regardless of whether Linux was running at the time DST is entered or left. > When the HWCLOCK setting is set to `--localtime', Linux will not > adjust the time, operating under the assumption that your system may > be a dual boot system at that time and that the other OS takes care of > the DST switch. If that was not the case, the DST change needs to be > made manually. As you can see it is up to system libraries and user settings how to provide DST. Org need not touch that, only convert from time zone time to UTC, from UTC to time zone time. > The 'solution' is to record this meeting in UTC tz. However, to make > this 'workable' for most people, the interface for managing timestamps > needs to make this easy. Then again you have to tell that it is "UTC", which means you are already specifying some time zone. You could tell that Org always thinks of UTC, but that again means UTC as mark, must be somewhere placed, all users must know that it is UTC, and again there is need for users to display time in their time zone. What do you achieve by that design? You will get confusion, as you are forcing majority of the world first to understand what is UTC. Computers don't do that, they ask you, where are you? Athens, Greece? Thanks, here is your time. They don't tell you "let us keep meeting time in UTC" confusing users. Follow the decade long trend human usability trend and use time zones. > For example, I would probablyh want an interface where by default, > my timestamps have no TZ data, but if I call the command to add a > timestamp with the universal argument, it will add a default tz and > allow me to easily change it to a different one. Time stamp does not need to have TZ data, and your function desire is just fine and co
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 author insist on it? (info "(org) iCalendar Export") >The iCalendar export back-end includes ‘SUMMARY’, ‘DESCRIPTION’, > ‘LOCATION’, ‘TIMEZONE’ and ‘CLASS’ properties from the Org entries when > exporting. To force the back-end to inherit the ‘LOCATION’, ‘TIMEZONE’ > and ‘CLASS’ properties, configure the ‘org-use-property-inheritance’ > variable. When exporting file or not exporting, the recipient may receive the file and be in different time zone. If file has no time zone property, then user in different time zone cannot know what time is being talked about. That means that function of sending appointments (headings or TODO tasks) should embed timezone property in such heading. Or the function that exports Org file shall embed something like #+TIMEZONE: PST in the Org file, or at least ask user, or allow such exports by customized functions. And all stamps like "Created: " in HTML shall get its time zone, because without it, time remains ambigous, and also in probably 98% cases wrong. Why display wrong time? If it is for user only, that is fine, but if HTML is published on web server for others, the time has significance. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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-20 Fri 09:00> He also has TIMEZONE (either system or Org file based) set to "EET". That way the time has been recorded in UTC for Org purposes, and UTC has been solved. For Greek user it is completely solved. Org calculates UTC based on configured time zone. But when it is 16:00 o'clock in Greece, it is 06:00 in Seattle. Online appointment is sent to user in Seattle, with the time zone PST. He receives the Org file from Greece, at 8:00 o'clock, which has settings inside TIMEZONE="EET". At first user thinks that appointment is in just 1 hour, because he can see "08:00", but Org gracefully notifies user that appointment is (probably) in a different time zone, and asks user if user would like to have it displayed in PST time zone. User answers with "Yes" and on his screen appears that meeting is actually at <2023-01-20 Fri 23:00>, he prepares himself for longer evening, and waits for his Greek partner on Jitsi Meet: https://meet.jit.si/ to get online. It confirms your hypothesis, yes, all times are calculated as UTC, but all time stamps at export, sharing, or change of time zone, shall be displayable in understandable manner to human user. > > Org in this state can't handle such things. > > Org can do the useful thing: translate the UTC timestamp into local time and > report both UTC and local time. User will be able quickly to determine if > local time is incorrect for some reason, such as DST or travel. Other way around, it has to translate time stamp into UTC time in the first place. Expecting that all user among so many various time zones write their time stamps in UTC is not reasonable. Org users are advanced, I know, but majority of note takers with other applications will not even think of different time zones, it is surprise they get when dealing internationally. People are not ready for calculating or even viewing their own time in UTC time zone, unless they are English or Icelandic, Portuguese, or Africans in parts of the West Africa. > Storing timestamps in UTC solves the interval problem Ihor > raised. Intervals always make sense in absolute time. Moving them > to event time leads to the insanity Ihor mentioned. The other way around. Assuming that time stamps are UTC raises problems for all other people: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png Org now does not support time stamps, right? So people write timestamps in their own time zone! Is it right? My time stamp here is <2023-01-19 Thu 17:12> now, what is yours? Forcing users to write time stamps in UTC would cause havoc. Thus time stamps already have their time zones, it is just not recorded in Org file. Options can be created so that: - user always and automatically record time zone in Org file, for example from system time zone, so that when first time property is invoked that it stays there: #+TIMEZONE: EET Or like this * TODO Appointment on Jitsy Meet with Greek investor DEADLINE: <2023-01-20 Fri 09:00> :PROPERTIES: :TIMEZONE: EET :END: or inside of the time zone. When such heading is read in Seattle, Washington, Org will tell to user or ask to translate it to PST time. In such translations, EET time is first converted to UTC, for reason of using system libraries, and not complicating Org, and then converted to PST time zone. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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't handle such things. A person in any timezone shall be able to see that time in his local time zone if we speak of distant meetings, and in case of face to face meetings, that person shall have computer aid to show him the meeting time in any time zone that user is located, during travel and upon arrival to face to face meeting. User is supposed to be assisted by computer. And not to assist to computer, or to get troubles from computer. - Time zone shall be more or less recognizable by city and country. - User addresses in the address book shall be part of every computer system - It is natural and common sense to know addresses of people one wants to meet - By using location of person one wants to meet, computer has got enough information for representation of the time zone - By sharing appointment record to user in other time zone, that user would see it in his time zone, or by choice in original time zone of the meeting place A record of time, shall have two attributes, the UTC time and the time zone to be displayed. By using system time zone setting, Org file time zone settings, heading time zone settings or time stamp time zone setting, any export of Org shall contain (by user's option) the desired representation of time stamps. Function of sharing of meetings shall ask local user: - is user in different time zone? And then by choice of the user's location, the time representation shall be prepared in such way that both parties understand each other. That is really not in the sphere of Org where there is not even a decent address book available. Just re-write the time by hand for your friend at other part of the world, write the timestamp in his time zone and your time zone, and problem solved. It is supposed to be text. It is not God. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
[SOLUTION] Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
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. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 supports (POSIX)? Yes, not too much. It is impossible. I would say this way, if user does not like Org task management without time zones, go and find other one without Org. Simple. Org does not have foundation where you can even think of complexities discussed here. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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-about-time > Falsehoods programmers believe about time Seems overwhelming to satisfy all requirement. 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? SELECT name, abbrev, utc_offset, is_dst FROM pg_timezone_names; name | abbrev | utc_offset | is_dst +++ NZ | NZDT | 13:00:00 | t GB-Eire| GMT| 00:00:00 | f Canada/Yukon | MST| -07:00:00 | f Canada/Atlantic| AST| -04:00:00 | f Canada/Pacific | PST| -08:00:00 | f Canada/Eastern | EST| -05:00:00 | f Canada/Central | CST| -06:00:00 | f Canada/Saskatchewan| CST| -06:00:00 | f Canada/Newfoundland| NST| -03:30:00 | f Canada/Mountain| MST| -07:00:00 | f Japan | JST| 09:00:00 | f Kwajalein | +12| 12:00:00 | f Egypt | EET| 02:00:00 | f Poland | CET| 01:00:00 | f Turkey | +03| 03:00:00 | f CET| CET| 01:00:00 | f Brazil/DeNoronha | -02| -02:00:00 | f Brazil/East| -03| -03:00:00 | f Brazil/West| -04| -04:00:00 | f Brazil/Acre| -05| -05:00:00 | f Chile/Continental | -03| -03:00:00 | t Chile/EasterIsland | -05| -05:00:00 | t EST5EDT| EST| -05:00:00 | f Atlantic/Jan_Mayen | CET| 01:00:00 | f Atlantic/Cape_Verde| -01| -01:00:00 | f Atlantic/South_Georgia | -02| -02:00:00 | f Atlantic/Faroe | WET| 00:00:00 | f Atlantic/St_Helena | GMT| 00:00:00 | f Atlantic/Azores| -01| -01:00:00 | f Atlantic/Madeira | WET| 00:00:00 | f Atlantic/Stanley | -03| -03:00:00 | f Atlantic/Bermuda | AST| -04:00:00 | f Atlantic/Canary| WET| 00:00:00 | f Atlantic/Reykjavik | GMT| 00:00:00 | f Atlantic/Faeroe| WET| 00:00:00 | f Iceland| GMT| 00:00:00 | f GMT0 | GMT| 00:00:00 | f EST| EST| -05:00:00 | f PRC| CST| 08:00:00 | f Cuba | CST| -05:00:00 | f Eire | GMT| 00:00:00 | t HST| HST| -10:00:00 | f GMT| GMT| 00:00:00 | f Greenwich | GMT| 00:00:00 | f CST6CDT| CST| -06:00:00 | f W-SU | MSK| 03:00:00 | f GMT+0 | GMT| 00:00:00 | f EET| EET| 02:00:00 | f Etc/GMT-2 | +02| 02:00:00 | f Etc/GMT-13 | +13| 13:00:00 | f Etc/GMT+2 | -02| -02:00:00 | f Etc/GMT+7 | -07| -07:00:00 | f Etc/GMT-12 | +12| 12:00:00 | f Etc/GMT-5 | +05| 05:00:00 | f Etc/GMT-11 | +11| 11:00:00 | f Etc/GMT0 | GMT| 00:00:00 | f Etc/GMT+6 | -06| -06:00:00 | f Etc/GMT| GMT| 00:00:00 | f Etc/Greenwich | GMT| 00:00:00 | f Etc/GMT+0 | GMT| 00:00:00 | f Etc/GMT+4 | -04| -04:00:00 | f Etc/GMT-6 | +06| 06:00:00 | f Etc/GMT+11 | -11| -11:00:00 | f Etc/GMT+8 | -08| -08:00:00 |
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 difference here. 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 will know it was night in their city when I was sending it. Time shall be displayed correctly to the person in that other time zone, preferrably in his time zone, not mine. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 should be job of underlying system functions. Org is only invoking addition by using system time: >From Org timestamp with time zone one has to use system functions, to add, or deduct time, then again to Org time representation. > 2. A user asks +1w date shift and the time zone has a 1-day jump during DST? >what about +7d? +1d? That is all for system functions to know. Is not good on the higher level (of Org) to start deciding about international issues that shall be recorded in C libraries somewhere, time zone databases, etc -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
* 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 waste a lot of resources; (2) > users dealing with these edge cases are likely already accustomed to > most programs not handling things correctly for their special time zone > situations. Org shall not handle that, only conversion between Emacs Lisp and system functions. Any maintenance shall be done on underlying level of system functions. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
