The Clock Behind the Commits: Measuring a Working Day in UTC
The challenge
feedparse-lite sits under three thousand packages and the original author, who had not touched it in two years, handed a stranger the keys after a run of good patches. Version 2.1.0 shipped with a postinstall script that is not in the git tag. Before anyone argues about intent, the thread wants a simpler thing established: the account claims Vancouver, and a person's working hours are very hard to fake because they are not a field anybody fills in. Six public records are on the board. Give the UTC offset this maintainer actually lives in.
What you'll learn
- Compare two timestamps of the same moment recorded in different clocks
- Read EXIF DateTimeOriginal as local wall time with no inherent offset
- Infer a working day and a lunch break from an activity histogram
- Discount profile fields and privacy-service WHOIS records as location evidence
- Explain why activity timing is harder to fake than any stated attribute
Skills tested
Prerequisites
- What UTC and a time zone offset are
- Reading a commit log
How it works
Almost everything on a profile is typed by the person it describes. Location, name, employer, photograph: all declarations, all free. What they cannot easily control is when they are awake, because their working day leaks into every timestamp a platform records for them, and platforms record in UTC.
The measurement needs two clocks showing the same moment. A post carries a server-side UTC timestamp. The photo attached to it carries DateTimeOriginal, which is the camera's local wall clock and, on a camera that writes no OffsetTime field, has no time zone attached at all. The gap between the two is the offset, and it is accurate to the minutes between shutter and upload.
Then check it. A correct offset turns a scatter of UTC timestamps into something recognisably human: a start, an end, a gap where lunch goes and nothing at weekends. A wrong offset turns it into someone who says good morning at eleven at night. In this case a whole day of separation is the tell, which is why the thread asked for a number rather than a country. The number is what the evidence supports; the country is a guess layered on top.
Common mistakes
- Answering UTC-7. That is Vancouver in August, and it is the claim under investigation rather than a finding.
- Trusting the WHOIS address. The registrant is a privacy service. Its street address is the service's, and it appears on thousands of unrelated domains.
- Reading the photo's timestamp as UTC.
DateTimeOriginalis the camera's wall clock. The record notes that no offset field is present. - Using only the commit log. It narrows the answer to a few plausible offsets. Pairing the post with the photo pins it exactly.
- Answering with a country. Several countries share UTC+3, and the evidence does not choose between them.
How to defend against it
For a project handing over commit or publish rights, identity is a process problem.
- Do not grant publish rights on the strength of good patches alone. A voice or video conversation, a reference from someone known, or a period of reviewed commits without release access all cost little and break this pattern.
- Require two maintainers to approve a release, and publish with provenance so the tarball can be checked against the tag it claims to come from. A postinstall script that is absent from the git tag should never have reached a registry.
- Watch for the shape rather than the person: a dormant popular package, an inactive author, a new account, rapid trusted status, then a release that differs from source.
- For consumers, pin versions, install with lifecycle scripts disabled, and take the delay between a release and adopting it. Most of these takeovers are caught within days by somebody else.