The DAA's "clock" is the chain's own block timestamps, with guardrails.

The period is every 2016 blocks (not "every two weeks"). TargetTimespan = 2016 * 600 = 1 209 600 seconds.
The clock source is header nTime values. Nodes don't ask NTP; they trust headers but bound them:

A new block's time must be greater than the MedianTimePast of the previous 11 blocks and also it must not be too far in the future (about +2 hours drift limit).

The retarget math is as follows:

actualTimespan = time(last) – time(first) over the 2016-block window
Clamp to [TargetTimespan/4, TargetTimespan*4]
new_target = old_target * actualTimespan / TargetTimespan

Then it converts target to compact "bits".

Therefore, the "two weeks" is just the nominal target; the real period can be shorter or longer, depending on how miners stamped the last 2016 blocks. The DAA doesn't assume the next 2016 blocks will match the last 2016 -- it's a feedback controller: if hashrate went up, actualTimespan shrinks and diff rises; if hashrate fell, diff drops. Individual block intervals vary wildly because proof-of-work is a Poisson process; the DAA smooths that only every 2016 blocks.

If you want to visualize it, print for a given height: and you'll see why some adjustments are "early" or "late" vs the calendar.