How does the DAA's Clock/Calendar work?

Every two weeks, the difficulty adjustment algorithm checks how many blocks were created in that time compared to what it expected, based on a target of ten minutes per block. If too many blocks are mined, it raises the difficulty, and if too few, it lowers it. So, my question is, what kind of clock or calendar is the algorithm using to figure out those block times? Do the developers rely on the timestamps in the block headers, or are they using internet time servers? As far as I know, the only consistent value in a block that relates to time is the nonce count, but you can't really figure out the block time without knowing the miner's hash rate (block_time = nonce_count / hash_rate). Regardless, the DAA seems to operate under the assumption that the next 2016 blocks will be similar to the previous 2016, which is never the case. That's why we see actual block times varying so much, anywhere from 0.3 seconds to 3 hours.

It relies on the block header timestamps, otherwise if it were to rely on the internet time-servers. There would be no point having to wait for 2016 blocks for another adjustments and there would also be a possibility of manipulations. Section 3 of the whitepaper gives a glimpse of it You can also look at this 1. https://bitcoinwiki.org/wiki/block-timestamp 2. https://gitbook-docs.coinmetrics.io/network-data/methodologies/normalizing-block-times

This is not true. The algorithm compares the average block time of the 2016 blocks mined in the last difficulty period with the expected average block time which is 10 minutes, not the number of blocks mined in the last two weeks with the expected number of blocks. Note that the difficulty period may be more or less than 2 weeks.

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.