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

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> Note that REST imply that almost arbitrary suffix can be in TIME without
>> braking the existing Org timestamp parsing code.
>
> I'm not sure how I feel about the REST in the grammar, I think it is a
> reasonable approach but need to double check. I'm worried that there
> can be some nasty interactions with REPEATER-OR-DELAY syntax, but that
> may not actually be an issue.

The existing code uses `org-ts-regexp-both' and `org-ts-regexp0' for
analysis. + `org-element-timestamp-parser' that is using Elisp logic.

And these requirements are pretty lax. The actual parsing just requires

YYYY-MM-DD [day] XX:XX[-XX:XX][optional string containing anything but "\n]>"]

with repeater and warning located anywhere after the required
date/day/time components.

date, repeater and warning periods do not have to contain " " afterwards
and thus can have arbitrary misc data. This feature is used by
org-habit, attaching things like /3w after the repeater.

We have a lot of forward-compatibility in timestamps :)

> I will note that this doesn't address the issue of syntax for
> historical and future dates. For historical dates those almost always
> require significant additional metadata to compensate for things like
> the julian/gregorian calendar switchover etc. for future dates we may
> want to go ahead and specify something beyond YYYY-.

This is somewhat orthogonal to time zones.

I am not sure if julian/gregorian is handled by system time libraries.
It should, no?

As for years BC, <-0001-...> will be a breaking change. But I do not
think that we need to really worry about this. Not unless we actually
get feature request. What is the practical application?

-- 
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>