[jmeyer2k]

Well, it relies on a synchronized clock, so it can't provide a clock. PoW adjusts the difficulty based on the time to try to meet some difficulty target.

In fact, if the time of nodes is not synchronized, it can cause significant problems and vulnerabilities. If time is too fast, the difficulty adjustment algorithm will think it mined too few blocks and decrease the difficulty.

[derefr]

Those aren’t really “significant problems and vulnerabilities”: any given node can lie about what time it is, but you’re not trusting a particular node for more than the outcome of a single contiguous block—and block difficulty “velocity” is capped—so you’d need a Sybil attack to actually walk the difficulty down. Otherwise, even at 49% malicious nodes, consensus is just going to bounce between nodes that say the time was really short, and nodes that give “regular” timestamps, keeping the difficulty roughly constant within the network’s margin of error.

Really, the timestamp field in most PoW systems’ “block” structs (Bitcoin’s, Ethereum’s, etc.) is just defined as “a number that is higher than the one in the parent block, and not so high that when interpreted as a POSIX timestamp it would land 30+ seconds in the future relative to the local node’s time.” So you just need >50% of the nodes to have a ±30s clock sync in order to agree on which blocks are valid for consideration; and even if you don’t have that level of synch, those blocks will still become valid eventually, once they’re old enough that all the nodes do consider them to be in the past. (And most PoW systems keep around near-“future” blocks until they’re valid for just such a case.)