I am currently learning agile
With respect, I'd suggest that you haven't got very far with that learning process. "Agile" is an adjective; not a noun. So you are learning agile techniques, or agile planning etc. You can no more "learn agile" than you can "learn sparkly" or "learn hot".
Let’s take an example from a project that I am currently working on the currently projects completion data is 5 months from now
Regardless of what process you are using to deliver a project, you cannot escape the "project management triangle" of scope, cost and quality. The moment you specify a deadline, the only way you can guarantee to meet that deadline is by compromising on one of the three corners of the triangle. You can spend vast amount of money on extra staff (though beware the mythical man month, often expressed as "you cannot employ nine women to deliver you a baby in one month"). You can cut right back on quality and release a bug-filled mess. Or you can release with less completed features.
The purpose of using an agile approach of frequent iterations, each of which is a theoretically releasable product is that you bring that triangle under more control. As you progress toward that deadline, you are always in a state of release-readiness, quality is kept high and costs are better monitored. You sacrifice large-scale scope always, but have frequent measures of the pressures on that scope that you can report to management.
Just beware them saying "what are you going to about it?" though when reporting on less than 100% delivery to their deadline. You can stand firm and insist that you'll deliver what's completed by that point in a robust fashion without compromising quality. Their only other option is to ask you to ramp up costs and cut quality so make sure they understand that that is what they are asking for if they want all the features by their deadline.
Secondly there is the cone of uncertainty...
The cone of uncertainty is related to the size of the backlog of work. The bigger the backlog, the greater the uncertainty. By breaking the work done into a series of iterations, you massively reduce that uncertainty ... for the current iteration. Each iteration is only tackling a small scope and so has a lower uncertainty. What such an agile approach doesn't do is magically remove the cone of uncertainty for the entire scope. That is why the logical next step after shifting projects over to an iterative process is to release after each iteration. That way the whole nonsense of large scope (not being) delivered in the distant future goes away. You have a series of smaller scopes with less risk and uncertainty that often can be delivered on time and the priorities of what goes in future releases is free to change after each short iteration and release.
And when you get to that point, you really will have "learnt agile" ;)