I'm certainly not the only dev who's run up against this, as multiple different attempts at implementing org-compatible clients (E.G., orgzly, nvim-orgmode) handle the edge cases differently.
Comments
Log in with your Bluesky account to leave a comment
Some uniformity: if possible, always shift to the same date of the following month (eg, jan 15 -> feb 15). This works up until jan 28th, at which point (unless it's a leap year) all subsequent shifts will now be bound to the 28th if the handler clamps to the closest date within the month.
If it instead falls back to "30 days" when it can't set the date, the new date is now fixed to the 3rd or 4th.
If we *always* use a 30 day shift, behavior is even less stable - as the new date on shift steadily slides back every other month, then jumps ahead in February.
Best course of action is unsure, but I think my solution here is just going to be handler flags to allow for different assumed behavior. If nothing else, the core data needed to implement your own interpretation of timestamp shifting is all there.
Comments
If we *always* use a 30 day shift, behavior is even less stable - as the new date on shift steadily slides back every other month, then jumps ahead in February.