Duration is defined as the number of calendar working time units between the
task's start and end date & time. If you have a task with 40 hours duration
being done by someone working on it 100%, the task requires 40 man-hours of
work and that work is being done over 40 hours of duration. If your calendar
is the default standard calendar it'll run perhaps Monday 8am to Fri 5pm.
But you need it done earlier than Friday at 5, you need it by Thursday at
the latest to fulfill your business objectives. You decide it's worth the
extra cost to pull in some overtime. In the split screen view on the
resource work form, you decide to assign the resource to work a total of 8
hours of overtime. Now the 40 hours of required work is being done as 32
hours straight time (ie, time inside the working time calendar hours) plus 8
hours overtime (time outside the working time calendar hours). But the only
thing that counts for duration is time inside the working time calendar so
the duration drops from 40 hours to 32 hours and that pulls the finish
forward from Friday at 5 to now land on Thursday at 5, now meeting your
requirements.
You shouldn't be "assigning dates" to tasks at all, telling Project the
dates you think they will occur. Project's job is to figure out the start
and end dates you will be able to achieve when you organise the work and
resources in a certain way, not merely to document some start and end dates
that you have somehow independently determined. It's your reality check on
whether you can realistically expect to achieve your objectives if you go
with the workflow and resource assignments as you've outlined it or if you
need to go back to the drawing board and try again. Trying to prevent it
from shifting start and end as you experiment with resources and assignments
negates the entire reason for having it in the first place.
HTH