When we talk about rounding down timestamps to weeks in Solidity, the operation typically looks like this:
Here, block.timestamp gives the current block's timestamp (in seconds since the Unix Epoch), 1 week is a convenience notation for 604,800 seconds (the number of seconds in a week), and the division followed by multiplication effectively rounds down the timestamp to the start of the current week.
This is a common pattern which is used to define weekly epoch starts.
Now, why does this operation always end up pointing to last Thursday at 00:00 UTC?
It's a fascinating interplay between how Unix timestamps work and the weekly calendar cycle. Unix time counts the seconds since the Unix Epoch (January 1st, 1970, at 00:00 UTC), which happens to be a Thursday.
Since a week is precisely 7 days or 168 hours, any whole multiple of weeks from the Unix Epoch will always fall on a Thursday.
This seemingly trivial detail has practical implications for projects. By rounding down to the nearest week, contracts that execute epoch-based logic can ensure a consistent starting point for new epochs.
This consistency is crucial for applications where events, actions, or changes must occur at regular intervals. The choice to start epochs on Thursday is not arbitrary but a direct result of the Unix timestamp's origin point.
For developers and projects utilizing this technique, it means that regardless of when an epoch-triggering transaction occurs, the new epoch will always start on a Thursday at 00:00 UTC. This predictability is valuable for scheduling, forecasting, and aligning events.