Tom Gillespie <tgb...@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>
