Reconstructed Time: Comment Timestamps in Interface-Level YouTube Extraction: A Measurement Report

Abstract

The extraction tool yt-dlp emits a Unix timestamp for every YouTube comment it retrieves. The field is not a measurement. YouTube's web interface publishes only a coarse relative label — one year ago, three weeks ago — and the absolute value is derived from that label by subtracting a bucket width from the clock at parse time. That the value is approximate is documented in the tool's own source and has been since 2021. It has not, to our knowledge, been measured. This report measures it. Across eleven extractions from seven videos (n = 461,083 comments), the mapping from label to timestamp is deterministic in ten of eleven: each distinct label corresponds to exactly one timestamp value, so the field carries no information beyond the label it was derived from. The resulting resolution loss is severe and scales with the age of the comments rather than with any property of the extraction. In one extraction, 182,784 comments occupy two distinct timestamp values, and 96.1% of comment pairs are exactly tied, which leaves pairwise temporal ordering undefined for almost the entire corpus. A validation against the YouTube Data API on five videos quantifies the error directly. Median absolute error rises from 4.1 days in a three-week-old corpus to 358.3 days in a two-year-old one. The error saturates rather than growing, so a two-year-old corpus is worse affected than a fourteen-year-old one.Two further failure modes are reported: an export in which the relative label is absent while the derived timestamp is populated, removing any visible indication that the value is reconstructed; and an extraction crossing midnight UTC, in which the same label maps to two different timestamps, making the value non-reproducible and capable of encoding extraction order as apparent temporal signal. A two-line detection test is given. One consequence reaches beyond temporal analysis. Recovering who replied to whom from the address marker YouTube inserts requires the replies of a thread in chronological order, and at least one research tool implements exactly that and states the requirement. Where the time axis is reconstructed, that order does not exist and the resolver breaks ties on extraction order. The API's time axis is not only needed for analyses about time. It is an input to analyses about structure, and the dependence is easy to miss because neither the question nor the output mentions time.