Meaning of "Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. "

In the Scrum guide is mentioned "Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less". 

@Aref Maleki, It just means that the Development Team has a more detailed plan for the work that will occupy them for the first few days of the Sprint i.e. Just enough planning, Just in Time. As they progress through the Sprint, by Inspecting and Adapting the Plan, more work will be decomposed to work on. By doing this you are preventing the risk of creating waste by planning too far ahead, especially if something changes down the line. 

Hope this helps.

If that's the case then the How part of the planning (planning 2) is not completed and the team needs to have another planning 2 for the rest of the stories to decompose?

How reasonable do you think it is to assume planning may be “completed” at all? Shouldn’t the Sprint Backlog be inspected and adapted continually throughout the Sprint?

How reasonable do you think it is to assume planning may be “completed” at all? Shouldn’t the Sprint Backlog be inspected and adapted continually throughout the Sprint?

Perfect point, as always

Remember that Scrum is only Scrum if you use it in it's entirety as described in the Scrum Guide.  Since part of Scrum is the Daily Scrum where the development plans their work for the next 24 hours, the only real need coming out of Sprint Planning is a plan for 24 hours.  As @Ian Mitchell so succinctly states, the plan will evolve daily. 

Thank you Ian Mitchell, Steve Vb and Daniel Wilhite

That is absolutely right that the Sprint Backlog will be reviewed and evolved during the Sprint but my point was completing the planning 2 for what have been picked up to work on during the planning 1. Definitely Sprint Backlog will be reviewed during everyday. My concern is if the team cannot finish the planning 2 how can they make sure they are really capable of delivering the items selected during the planning 1 and commit to the PO.

In my case the developers creating the sub-tasks and there was a time that time-box was over but they couldn't finish creating the sub-tasks for all the stories. They asked me what to do and I said if you have enough stuff to begin with you can create the sub-tasks for the rest later. Then I was told that "we cannot commit if we didn't think about all the sub-tasks" and my answer was then you have to continue the planning 2 till all stories are covered. 

Then I was told that "we cannot commit if we didn't think about all the sub-tasks" 

I am assuming that the team is not waiting until all of the subtasks are identified before estimating?   If so, they should be able to agree to a forecast based on their known velocity/capacity, and the items that they are being offered.

While understanding all of the subtasks for an item can help improve estimation accuracy, it should not be treated as a prerequisite by the team.   Estimation is an imperfect science - it is based on "guesswork" around the understanding of the item at that time.

See if you can work with the team to help them become more comfortable with estimation and forecasts without the residue of Big Planning Up Front.

Then I was told that "we cannot commit if we didn't think about all the sub-tasks"

Did you ask why? Why is it unreasonable to commit to a Sprint Goal when tasks are allowed to emerge?

...commit to the PO

Then I was told that "we cannot commit if we didn't think about all the sub-tasks" 

Where in the Scrum Guide does it state that the Development Team has to commit? The Development forecasts the amount of work that can be done to satisfy the Sprint Goal based on the information that is known at the time of the forecast. As new information is uncovered, that forecast is inspected and adapted.  The whole idea is to discuss the goal constantly during the Sprint time box. The chances of the team correctly identifying all of the needed tasks for a story on day 1 of the Sprint is at best 50%. 

If your PO is expecting a commitment, then I see a coaching opportunity for you.  If the Development Team feels that they have to provide a commitment, again you have a coaching opportunity.  Trust is absolutely necessary.  Trust that no one on the Scrum Team will intentionally do something that will cause harm. Without trust the chances of team success are greatly diminished. 

Thank you all for your valuable responses.

Actually the trust is there from PO but recently we had some changes in the organisation therefore the team is trying to play with some words however they are delivering on time with quality and also we started to create sub-tasks for because of the recent changes and that's why they keep saying we want to commit to the Sprint after creating all the sub-tasks. 

But I tried to moderate the situation to tell them that we never can be 100% sure of anything so that we plan and commit based on current situation however when the creating sub-tasks is done if you need to adjust the sprint you always can discuss it with the PO. 

In addition, there were some concerns about the sub-tasks that would lead to micro management as we had them in Jira so to assure them that is not the case we decided to have the sub-tasks in physical board so they really feel that it is solely belong to them not anyone else out of the team.