It's an interesting idea, thanks! It would be nice to provide a constraint that makes this kind of movement easier. We'll give it some thought.

That's an interesting idea and something I've used before, for 3d. I wonder if it might give some issues for certain looped animations and if it would always play nice at runtime.

I did some testing on the constraint and the results were ok animation wise. However at runtime we run into some problems so it's unlikely we will add timeOffset.

The good news is that it's not very hard to get what you're after with a few simple steps.

1. Create a single bone which has the entire length of the tail.
2. Disable Inherit Rotation on the bone.
3. Click Split and make sure Nested is enabled. Choose the amount of bones you want, for example, 10.
4. In animate mode select all bones and key their rotation, I went with 45, 315, 45.
5. select the bones in order so they appear in order in the dopesheet.
6. enable Offset and offset each bone at an increment of 5 frames. So 5,10,15,20 etc.

Here's what I ended up with by doing the above.

Image removed due to the lack of support for HTTPS. | Show Anyway

Note that in some cases you might want to keep rotation inheritance and instead use transform constraints. I've included a project file that contains both.

wavyMotion.spine

I'm not a programmer so I can't explain the runtime issues very well. However, it has to do with the offset potentially looping to the end of an animation, a part which has not yet been played. Essentially it means an animation will need to be played once and then cached. I'm sure one of the programmer savvy guys can explain it better.

The feature you'd like is that a bone will be given the value (eg rotation) of another bone at a different animation time. The issue is that a timeline doesn't have information about how a skeleton was posed at a different animation time. A skeleton's pose for a particular time can come from many things: one or more mixed and/or layered animations, constraints, user application code, etc. Even if we could simplify by saying the bone will get the value from timeline X at a different time, how would that work as a constraint? Constraints are applied by updateWorldTransform after the skeleton is posed and they don't know about what animation/timelines were applied. We could special case something so that applying an animation would also apply any time offset constraints, but even then the constraint would have to dig through all the timelines to find the one for a particular bone so it can calculate values for different times. That is possible but not great since there could be a few hundred timelines. Maybe the animation could do something to make looking up timelines for a particular bone faster, but it's feeling a bit hacky for something that could be keyed as Shiu has shown.

How about allowing to stagger/align/offset keyframes from child bones only in the editor? It could be still very useful, and not so painful on the runtimes, couldn't it?
Something that sees where the current animation ends and staggers frames putting them back to the beginning, maybe?

It could be done, but isn't terribly simple to implement. I feel like there are lots of higher impact features that are needed first.

I was about to post this topic and was happy to find it already existed : )

For adding transform constraint time offset, I've had an idea on how it might be simpler to implement.
For every time-offset transform constraint, Spine could internally create a second animation with keys only for the bones controlled by the constraint. It would then mix this internal animation with the user's animation, but start the internal animation only after the offset time.

Does this make sense? Would it simplify implementation?

The other animation would need to contain everything that affects the transform constraint target bone: parent bones, other constraints, etc. This is possible, but not super simple. It wouldn't take into consideration any user code that manipulates bones, but this is less common. It wouldn't take into consideration animations on other tracks, if using AnimationState. It is an interesting idea and might simplify the implementation slightly, but it's still not simple.