emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: Ignacio Casso <ignaciocasso@hotmail.com>,
	emacs-orgmode@gnu.org, tom@tomdavey.com,
	Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)])
Date: Wed, 23 Mar 2022 21:13:42 +0800	[thread overview]
Message-ID: <87y210stfd.fsf@localhost> (raw)
In-Reply-To: <87pmmdsm2f.fsf@gmail.com>

Tim Cross <theophilusx@gmail.com> writes:

> I think we have to be very wary here. I can see any changes here causing
> lots of breakage for people. I know for my own use case, I use
> timestamps a lot in property draws and various source blocks. I never
> want any of them showing up in my agenda.

FYI, the default agenda behaviour around a month ago was exactly what
you want to avoid (assuming that you use active timestamps). I explained
in more details in https://list.orgmode.org/87h77psaik.fsf@gmail.com/T/#me4f41a8b36ada384d87cf028ef10164dfa526ad2
Let's keep discussion of the original issue in the original thread.

> Unfortunately, I think org timestamps is a bit of a mess and we need to
> be very careful about further complicating matters. The inability to
> handle timezones is a major limitation IMO. The inability to handle
> daylight savings transitions in a consistent manner (particularly for
> calculation of periods, duration, etc) is often a source of errors and
> if you are unfortunate enough to regularly travel across different
> timezones, forget about using org mode to manage your schedule.
>
> I have done several deep dives into org-mode's timestamp stuff, but
> usually come back up gasping for air. Managing data and time data is
> often far more complicated than it may appear on the surface. I think we
> need to be extremely conservative when considering changes in this area
> (it is the main reason I've never managed to find a way to add time zone
> data - every solution I could think of was either really high on the
> level of breakage and frustration it would create for users or it
> adversely impacted the convenience/usability of org timestamps). 

I sympathise with you. I still remember my struggle when I had to travel
across multiple time zones. Anyway, the timezone issue have been
discussed multiple times within last 10 years or so. It is complex and
nobody managed to come with a good idea how to approach it.

Best,
Ihor



  parent reply	other threads:[~2022-03-23 13:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-12 10:06 [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)] Ignacio Casso
2022-03-12 12:28 ` Ihor Radchenko
2022-03-21 15:58   ` Tom Davey
2022-03-21 23:21     ` Ignacio Casso
2022-03-22  0:50       ` Samuel Wales
2022-03-22 10:02         ` Ihor Radchenko
2022-03-22 10:17         ` Ihor Radchenko
2022-03-22 21:02           ` Tim Cross
2022-03-23 12:07             ` Ihor Radchenko
2022-03-23  0:10           ` Samuel Wales
2022-03-23 12:21             ` Ihor Radchenko
2022-03-24  3:38               ` Samuel Wales
2022-03-22  3:43       ` Tom Davey
2022-03-22  9:47       ` Ihor Radchenko
2022-03-22 10:00         ` Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Ihor Radchenko
2022-03-22 21:10           ` Tim Cross
2022-03-22 23:16             ` Tom Davey
2022-03-23  0:25               ` Tim Cross
2022-03-23 13:13             ` Ihor Radchenko [this message]
2022-03-22 23:05           ` Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions Nicolas Goaziou
2022-03-23 13:06             ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y210stfd.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ignaciocasso@hotmail.com \
    --cc=mail@nicolasgoaziou.fr \
    --cc=theophilusx@gmail.com \
    --cc=tom@tomdavey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).