Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Daryl Manning <daryl@wakatara.com>]

[-- Attachment #1: Type: text/plain, Size: 5684 bytes --]

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 <yantar92@posteo.net> wrote:

> Tim Cross <theophilusx@gmail.com> 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 <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[-- Attachment #2: Type: text/html, Size: 7299 bytes --]