Ah yes, I've reached the "finding out" part of "I'll just fuck around and write code that deals with datetimes"... for like the millionth time. Org documents state: "With the ‘+1m’ cookie, the date shift is always exactly one month." What, pray tell, is an exact month? - ThreadSky

About ThreadSky

totooria.bsky.social • 59 days ago

Ah yes, I've reached the "finding out" part of "I'll just fuck around and write code that deals with datetimes"... for like the millionth time.

Org documents state: "With the ‘+1m’ cookie, the date shift is always exactly one month."

What, pray tell, is an exact month?

Comments

totooria.bsky.social•59 days ago

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.

totooria.bsky.social•59 days ago

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.

totooria.bsky.social•59 days ago

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.

totooria.bsky.social•59 days ago

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.

Posting Rules

Be respectful to others
No spam or self-promotion
Stay on topic
Follow Bluesky's terms of service

Comments

Posting Rules

Reply