What is the DAA's Clock/Calendar?

[SapphireSpire]

Every two weeks, the difficulty adjustment algorithm compares the number of blocks over the previous two weeks with the expected number of blocks, given a target block interval of ten minutes, and adjusts the difficulty up if there's too many blocks or down if there are too few blocks.

My question is, what clock/calendar does the algorithm depend on to determine block times?

Would the developers trust time stamps in the block headers, or internet time servers? AFAIK, the only reliable value in a block of which time is a factor is the nonce count, but it's not possible to calculate the block time without also knowing the miner's hash rate (block_time = nonce_count / hash_rate).

In any case, the DAA assumes that the next 2016 blocks will be the same as the last 2016 when they never are and that's why actual block times are all over the place, anywhere between 0.3 seconds to 3 hours.

[logfiles]

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

[hosemary]

Every two weeks, the difficulty adjustment algorithm compares the number of blocks over the previous two weeks with the expected number of blocks, given a target block interval of ten minutes, and adjusts the difficulty up if there's too many blocks or down if there are too few blocks.

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.

[BattleDog]

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:

Code:

time(h) – time(h-2016)

and you'll see why some adjustments are "early" or "late" vs the calendar.