I think that your second image is a template that you should use to plan out your Sprints. Where did you get the image?
You do a longer release planning with Scrum by:
- organizing your backlog with proper priorities for the items;
- do a rough estimate of the backlog items;
- then using your team velocity and known duration of a sprint, try to figure out how many sprints you will need to run through all of the backlog items.
The approach is already described on the site, for example here: How do you schedule delivery dates in Scrum?
So yes, your project sprint schedule should contain backlog items in each sprint. You say "tasks", but tasks are too fine-grained for that. Most likely you will have epics that you sized against one another then figured out which ones you could stick into which sprints.
Now, as others have pointed out, this doesn't mean that your estimate and your planning will actually happen. If you planned something in sprint 6, starting on 10 October, it doesn't mean that it will happen and you will actually work on it. And this isn't a problem with Scrum or an adaptive methodology; this is a problem with the nature of software development and estimates. Estimates are forecasts, not promises, and not commitments, because things can change with time.
For example, the things that can happen with your planned sprints can be this:
- you estimate and plan out your features by fitting them nicely into sprint boxes;
- in sprint 1 you should work on X;
- in sprint 2 you should work on Y;
- in sprint 6 you should work on Z;
So far, this planning isn't any different than Waterfall or a predictive approach. The difference is that in Waterfall for example, you start working on the features and at the end of the project you show everything to the customer, or at (large still) milestones at best. And the customer doesn't like it, or finds the application unusable, or doesn't solve the full problem, etc. Why? Because at the beginning of the project you know the least about the project. So all your planning, schedule, and Gantt charts will probably be just a high dose of wishful thinking built on unknowns and assumptions (including the assumption that things won't change or deviate from plan). Agile, instead, recognizes these problems and the fact that things will change.
So what happens in something like Scrum, instead? Well, you do sprint 1 and work on X. You show X to the client and client is satisfied. Then you do sprint 2 and work on Y. You show Y to the client and the client sees it's not what they truly wanted. They gain insight into the product. So with that new insight, they might now think about it some more and realize that they don't need Z either. And now, your planned Sprint 6 that needed to start on October the 10th by working on Z is useless because you won't do it anymore. You need to redo your long term planning and see what you could do in Sprint 6 instead of Z, because the client just changed their mind.
Do these re-plannings often enough and in time you realize that long term planning is a waste when working on something that you don't really know how it should look like.
As Daniel pointed out in his comment above, when you know exactly what you need and how to build it, you plan it predictive style and you can decide on a schedule (but even like this, there might be some variance). If you work on something that isn't clear or has a lot of unknowns and assumptions, you can instead build it step by step and decide after each step what to do next; so at this point it doesn't make any sense to plan a lot of sprints in advance because at each step your plans and schedule can change.