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 <yanta...@posteo.net> wrote: > Tim Cross <theophil...@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> >
