Time

Every header says when its block was made. The time is written as a Unix timestamp: the number of seconds since midnight UTC on 1 January 1970.

The miner fills it in, so it’s a claim, not a measurement. Nodes don’t trust it blindly: they only accept times inside a narrow window. Pearl’s window is much tighter than Bitcoin’s, because Pearl retunes its difficulty after every block using these very timestamps.

Try it

The converter starts at 1,792,513,562, the time of block 130,827. Its hex is 6ad7961a, and its 4 bytes in little-endian order are the ones stored in the header.

What does it look like?

Size

4 bytes

Type

Unsigned integer (Unix seconds)

Format

Little-endian

Range

0 to 4,294,967,295 (until the year 2106)

Bytes 68 to 71 of block 130,827 are 1a 96 d7 6a. Read little-endian, backwards, that’s 0x6ad7961a:

Whole seconds only, no time zone: it’s always UTC. And because the field is an unsigned 32-bit number, it runs out in the year 2106, as Pearl’s code comment notes.

What are the rules?

Two, one on each side:

Pearl’s own code was run on the edges to confirm them:

“Network-adjusted time” is the node’s own clock, corrected by the median offset reported by its peers (offsets beyond ±70 minutes are ignored), the same logic btcd uses.

Why so strict?

Because of how Pearl sets its difficulty. Bitcoin looks at time once every 2,016 blocks. Pearl’s WTEMA rule looks after every block: the next block’s target is nudged according to how long the last block took, its timestamp minus its parent’s.

• The 1-second rule keeps that gap positive. The code comment says it plainly: the rule is “required for WTEMA difficulty adjustment”.
• The 5-minute rule limits how far a miner can bend a gap by lying about the time. One week of lateness changes the target by a factor of about e, so 5 minutes of fake lateness moves the next target by only about 300 ÷ 604,800 ≈ 0.05%, and the next honest timestamp gives it back.

The details of WTEMA are in WTEMA and timestamps.

What do real Pearl timestamps look like?

A few landmarks, straight from the chain:

Blocks 1 to 5 are exactly one second apart: at launch, difficulty was at its minimum and miners found blocks as fast as the rule allows. Since then WTEMA has pulled the pace toward the 194-second target. Recently blocks have come a little faster than that: the average over the last 144 blocks is 174.3 seconds.

Where else does time matter?

• In the mining puzzle. The timestamp is one of the first 76 header bytes that are hashed into the job key. A new timestamp means new noise and new tickets, a fresh job. Pearl’s toy miner gets new jobs exactly this way.
• In lock times. The median time past of the last 11 blocks is still computed, and it still decides when time-locked transactions become valid (BIP 113 and relative lock times), exactly as in Bitcoin. Only the block-timestamp rule changed.

// Enforce strict timestamp monotonicity: each block's timestamp
// must be at least MinTimestampDelta seconds after the previous block.
// This is stricter than the original median-time rule and makes the
// median time check redundant. Required for WTEMA difficulty adjustment.
prevTimestamp := time.Unix(prevNode.Timestamp(), 0)
minTimestamp := prevTimestamp.Add(time.Duration(MinTimestampDeltaSeconds) * time.Second)
if header.Timestamp.Before(minTimestamp) {
	return ruleError(ErrTimeTooOld, str)
}

maxTimestamp := timeSource.AdjustedTime().Add(time.Minute * time.Duration(maxTimeOffsetMinutes))
if header.Timestamp.After(maxTimestamp) {
	return ruleError(ErrTimeTooNew, str)
}