From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id KKc9B8mRwmN/bAEAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 12:28:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id WNj1BsmRwmNEuQAAauVa8A (envelope-from ) for ; Sat, 14 Jan 2023 12:28:09 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A5AF52553C for ; Sat, 14 Jan 2023 12:28:08 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGehE-0008Q2-QE; Sat, 14 Jan 2023 06:27:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGehC-0008PI-60 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 06:27:34 -0500 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGeh9-0005Xe-3k for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 06:27:33 -0500 Received: by mail-wm1-x32c.google.com with SMTP id m8-20020a05600c3b0800b003d96f801c48so20344128wms.0 for ; Sat, 14 Jan 2023 03:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakatara.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uJF5rSQwxB7D1evgmlEfbcidj5a9IjpCypC2dKaa9U8=; b=BPqWjcqAspRvij7nhsR7NgzQ6UVhzyliblT1ser3tINSCl4W2/RFLEffpxBxcxRdg9 dZYXpcqCgG9Aa1JyHMMWgVggEYwuqpYRTuQlMg0ebM+tw4FWkdB5j56fsTLZK1R1iTOo j4LlDyBwJpRHKScRd7YUSOq4B8FaZ8R6dPoIjzW/BBWDlxmCQDFbmXlkJbP7LjDnT0AN UoWocrJBTD7B4PWgT6vYdb/PTZBGm4DCf2YlmutAC8KHBKybWQro2EPbBa8WnkCCukcS JiAdzak/KU9kwtWCWlSUoFH2a+mcperk8FrgdKDjJAnu+I5RAnt/1XQ/mX7eFOfoX569 n3bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uJF5rSQwxB7D1evgmlEfbcidj5a9IjpCypC2dKaa9U8=; b=o36UElZ6M9mv3i9mUTIbGqSdVJEGrTGi9JLIlGDd3UNE2tpEYFMlfx/njT05ORbXWy S+6Qc55sziCEO+VTYJC/rEECDiLeTaCUxwDNGl5QGPyg/mBFVKftTAJA/wdsiSjD30wV 0wQsyXeQCd4Z9XLDSEC/f+LCFMvmJnStBEhfjltftBmniyrC3rUmdNWXS1Cj9O4m64CM RaTfoxVxKGiYeYkLnr/tW3C2+C3qBrTnUHDSnXsEaoJFATkmj5fb7xr8mbKcoUPF6w+T uvjlGv20Rt0aE4L1RD3wEGM+6X2nnT+NiqqHL8H8VyvFUavFxdZ0IC71MhUXDJytPMPU GxRw== X-Gm-Message-State: AFqh2kri016C5DX5Yrg9ACzKdEJlEXKiPpMTTFhI+qQAq3/LEp8TrYQe 7zayEbLb4jRgLgnZIwLiwfgltm9p1H56ySD2nkTO6Q== X-Google-Smtp-Source: AMrXdXu/BpM/T8vzhcv7ViMakFQ+kdzsysOVwSUEElVW2SlXSgXsdUH5p8XvZ/36zDTq57gOgpFfhGGC4yPCFDfC3aI= X-Received: by 2002:a05:600c:3106:b0:3da:b66:5ade with SMTP id g6-20020a05600c310600b003da0b665ademr669481wmo.157.1673695647779; Sat, 14 Jan 2023 03:27:27 -0800 (PST) MIME-Version: 1.0 References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> In-Reply-To: <87tu0t1i0c.fsf@localhost> From: Daryl Manning Date: Sat, 14 Jan 2023 18:26:51 +0700 Message-ID: Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda To: Ihor Radchenko Cc: Tim Cross , emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000008c6af705f237a27f" Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=daryl@wakatara.com; helo=mail-wm1-x32c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=BPqWjcqA; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673695688; a=rsa-sha256; cv=none; b=t9OzG0v/IpzUCpePMfPkCOMhB+iIWARTgELntLx2ksnCkH6aUyOO4opgc28qGNM8AcnWgo 3rYWfAI9P683gBJ3c8pPeUv110vGPqHq9ZsHCbLObY3t9UqZdd+8kJg6w90T+TuGEbAWAL jZ16SLSkiUjXB1LAC013GUWdzJHzme1QpWX8yMSwaXZwWQWkxQnkTLT1NX33AMnrN7I4R3 +aKpUttH0u/t7JL4cf72vK8kH2G0K5g80gVuHoAbVoz9vXdLpOVLppjJL8w4N5z6scZCPJ 3u43Gg5+D6NYgNptZECxfSJw3vpoW8vzLhvXnb2+9UNpDDi2/MeafSy3Z60xzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673695688; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=uJF5rSQwxB7D1evgmlEfbcidj5a9IjpCypC2dKaa9U8=; b=mkL4pyD7IMCb60fLHL6AwMgS392Hnqs8pLGBp1RXY07WehwRZhpnye7mWdfWIq5YefeCHP DRQK3IKKH85yzMev9ekXtl/dVlTnKw/rfMC7uzf3E8euc4u8ST9w4T40wQs3vL+cRvFnZN j/gt38dc7F4qhgeuk8sp0PVgpkwjOtInnPh7IsnTlRh3F3nHkJSN8SM5E1OCripcpfBouG HRgsaXNbJ03SBQ+xKefanEWuyka8ZLUfKwVzf1Y6ApJ7vbOcA0hA7b06ob3TnaYAGX+cQC s1O2rcyfsJCYtAbH10Hvt7YbZaPDHT3ikbwwBfPWhl8WwkGhjzr5jj27xS63dw== X-Migadu-Queue-Id: A5AF52553C X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=BPqWjcqA; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-Migadu-Spam-Score: -3.61 X-Spam-Score: -3.61 X-TUID: XaL6UZChA45T --0000000000008c6af705f237a27f Content-Type: text/plain; charset="UTF-8" Hey Ihor, Sorry, I had a little trouble understanding the way you have the syntax written in that timestamps doc. Can you give an example like below? What does it look like? And say, with a recurring data like once a week and a warning of 5d early? I believe /most/ people would be looking for something grokable like: <2023-01-14 Sat 18:22 SGT> or say <2023-01-14 Sat 18:22 +08> (tho I imagine the second example would break repeats syntax though) primarily useful in TODOs etc. Daryl. On Sat, Jan 14, 2023 at 6:18 PM Ihor Radchenko wrote: > Tim Cross writes: > > > I agree this would be a great feature to add. However, after having > > looked at it in some detail, I realise that not only is it not a trivial > > task, it is actually a very large and complex task and will require > > extensive work which will almost certainly result in breakage with > > regards to backwards compatibility. > > Not really. Our timestamp format, in fact, provides sufficient > flexibility to add extra metadata to timestamps. > > In anticipation to add time zones in future, I have added the following > to the Org timestamp spec (see > https://orgmode.org/worg/org-syntax.html#Timestamps): > > DATE TIME REPEATER-OR-DELAY > > TIME (optional) > An instance of the pattern H:MMREST where H represents a one to two digit > number (and can start with 0), and M represents a single digit. REST can > contain anything but \n or closing bracket. > > Note that REST imply that almost arbitrary suffix can be in TIME without > braking the existing Org timestamp parsing code. > > REST, among other things may be > https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid > value of TZ POSIX variable. Exact details can be discussed. > > Note that TZ should be fully supported by `encode-time' (ZONE): > > (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE) > > We do not need to worry about internal representation and conversions > and simply rely on Emacs. > > > At the risk of over simplifying the matter, I would suggest the big > > challenge here is that there are two somewhat competing (and > > conflicting) use cases. On one hand, you want a high level abstraction > > which makes working with dates and times easy and clear. TO some extent, > > that is what we have now. On the other hand, we need something far more > > complex which is able to handle multiple time zones. This means being > > able to handle both base timezone offsets as well as offset adjustments > > for things like daylight savings time. There is a lot of hidden > > complexity here. You have to handle the fact that daylight saving > > chang-over dates/times are dynamic i.e. not necessarily the same every > > year. This adds the additional complexity of having to somehow track > > historical information regarding such changes, which isn't as readily > > accessible in a consistent manner on all platforms. > > We do not care about the details as long as Emacs can handle this. As > long as the user supplies DST and ZONE somehow, we can rely on Emacs' > support and system TZ implementation. > > > Then there is the other 'messy' stuff. For example, when calculating > > time ranges and number of days, hours/ minutes between two dates you > > need to remember to add/remove the hour if the range crosses over a > > daylight savings period. Similarly you need to ensure you make the > > correct adjustment when changing timezones (consider emacs on a laptop > > for someone who travels a lot between different time zones). Not only do > > you need to take into account the different timezone offset, you also > > need to look at the date and then adjust according to the timezone > > offset for the current timezone at the time of the timestamp rather than > > just considering the current time offset. > > Again, we don't need to worry about this. Once we use `encode-time', > operations on time should just work. This is what we do anyway in most > of Org code. > > > I expect what is needed is an 'internal' UTC based representation which > > is used for all calculations and an 'interface' layer, which converts > > the UTC representation into the local display representation for > > consumption by humans. > > This is what we already to via `encode-time' and `decode-time'. > Check out `org-time-string-to-time'. > > > However, the real challenge here is that this is a very large piece of > > work and it needs someone who is prepared to take it on. I suspect until > > someone who needs to scratch this itch sufficiently comes along, this is > > a feature which will be unlikely to make it to the top of the todo > > list. There are simply far too many existing feature improvements and > > additions people will prefer to work on before taking on this > > one. Things are made more difficult because it isn't the sort of task > > which can be achieved with small increments over time. This is more > > likely to be something which needs to be developed in a feature branch, > > which once it reaches a sufficient level of completeness can be used and > > verified working for a wide variety of environments before then working > > out how to fold it back into the core system and handle whatever change > > management will be necessary. > > Not as much as you describe. Not small work either though. > Most of the machinery is already in place, except some leftover pieces > from early Org days. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --0000000000008c6af705f237a27f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Ihor,

Sorry, I had a= little trouble understanding the way you have the syntax written in that t= imestamps doc.

Can you give an example like be= low? What does it look like?
And say, with a recurring data like = once a week and a warning of 5d early?

I belie= ve /most/ people would be looking for something grokable like:
<2023-01-14 Sat 18:22 SGT> or say
<2023-01-14 Sa= t 18:22 +08>
(tho I imagine the second example would brea= k repeats syntax though)
primarily useful in TODOs etc.

Daryl.







=C2=A0 <= /div>

On Sat, Jan 14, 2023 at 6:18 PM Ihor Radchenko <yantar92@posteo.net> wrote:
Tim Cross <theophilusx@gmail.com> writes:<= br>
> I agree this would be a great feature to add. However, after having > looked at it in some detail, I realise that not only is it not a trivi= al
> task, it is actually a very large and complex task and will require > extensive work which will almost certainly result in breakage with
> regards to backwards compatibility.

Not really. Our timestamp format, in fact, provides sufficient
flexibility to add extra metadata to timestamps.

In anticipation to add time zones in future, I have added the following
to the Org timestamp spec (see
https://orgmode.org/worg/org-syntax.html#Timestam= ps):

DATE TIME REPEATER-OR-DELAY

TIME (optional)
An instance of the pattern H:MMREST where H represents a one to two digit n= umber (and can start with 0), and M represents a single digit. REST can con= tain anything but \n or closing bracket.

Note that REST imply that almost arbitrary suffix can be in TIME without braking the existing Org timestamp parsing code.

REST, among other things may be
https://en.wikipedia.org/wiki/ISO_8601#T= ime_offsets_from_UTC or a valid
value of TZ POSIX variable. Exact details can be discussed.

Note that TZ should be fully supported by `encode-time' (ZONE):

(SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

We do not need to worry about internal representation and conversions
and simply rely on Emacs.

> At the risk of over simplifying the matter, I would suggest the big > challenge here is that there are two somewhat competing (and
> conflicting) use cases. On one hand, you want a high level abstraction=
> which makes working with dates and times easy and clear. TO some exten= t,
> that is what we have now. On the other hand, we need something far mor= e
> complex which is able to handle multiple time zones. This means being<= br> > able to handle both base timezone offsets as well as offset adjustment= s
> for things like daylight savings time. There is a lot of hidden
> complexity here. You have to handle the fact that daylight saving
> chang-over dates/times are dynamic i.e. not necessarily the same every=
> year. This adds the additional complexity of having to somehow track > historical information regarding such changes, which isn't as read= ily
> accessible in a consistent manner on all platforms.

We do not care about the details as long as Emacs can handle this. As
long as the user supplies DST and ZONE somehow, we can rely on Emacs' support and system TZ implementation.

> Then there is the other 'messy' stuff. For example, when calcu= lating
> time ranges and number of days, hours/ minutes between two dates you > need to remember to add/remove the hour if the range crosses over a > daylight savings period. Similarly you need to ensure you make the
> correct adjustment when changing timezones (consider emacs on a laptop=
> for someone who travels a lot between different time zones). Not only = do
> you need to take into account the different timezone offset, you also<= br> > need to look at the date and then adjust according to the timezone
> offset for the current timezone at the time of the timestamp rather th= an
> just considering the current time offset.=C2=A0

Again, we don't need to worry about this. Once we use `encode-time'= ,
operations on time should just work. This is what we do anyway in most
of Org code.

> I expect what is needed is an 'internal' UTC based representat= ion which
> is used for all calculations and an 'interface' layer, which c= onverts
> the UTC representation into the local display representation for
> consumption by humans.

This is what we already to via `encode-time' and `decode-time'.
Check out `org-time-string-to-time'.

> However, the real challenge here is that this is a very large piece of=
> work and it needs someone who is prepared to take it on. I suspect unt= il
> someone who needs to scratch this itch sufficiently comes along, this = is
> a feature which will be unlikely to make it to the top of the todo
> list. There are simply far too many existing feature improvements and<= br> > additions people will prefer to work on before taking on this
> one. Things are made more difficult because it isn't the sort of t= ask
> which can be achieved with small increments over time. This is more > likely to be something which needs to be developed in a feature branch= ,
> which once it reaches a sufficient level of completeness can be used a= nd
> verified working for a wide variety of environments before then workin= g
> out how to fold it back into the core system and handle whatever chang= e
> management will be necessary.

Not as much as you describe. Not small work either though.
Most of the machinery is already in place, except some leftover pieces
from early Org days.

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--0000000000008c6af705f237a27f--