A Researcher's Guide to Reddit Timestamps

A Reddit record carries a created_utc field: seconds since the Unix epoch, in UTC. It looks like the one field that cannot cause trouble.

It causes a specific, quiet kind of trouble, and the trouble is mostly about where you convert it.

Two timestamps, not one

Archive records often carry two: created_utc for when the content was posted, and retrieved_on for when the archive captured it.

The gap between them is not trivia. It determines whether the score is real. Records captured close to posting carry placeholder scores rather than actual ones, so retrieved_on - created_utc tells you whether a score can be trusted.

Most tools ignore retrieved_on entirely, which is why so many archive score statistics are quietly wrong.

The bucketing problem

Here is where reproducibility breaks.

Grouping records by month requires deciding which month a timestamp falls in. That depends on the timezone you convert to. A post at 23:30 UTC on 31 March is in March for a researcher in London and April for one in Sydney.

Run the same analysis on the same data in two places and get two different charts. Nothing errors. Both look plausible. Neither is reproducible.

The fix is to bucket in UTC always, and treat local time as a display concern. If someone wants to see hours shifted to their timezone, shift the display — never the value used for grouping.

This sounds fussy until you have two analyses of the same dataset that disagree and no idea why.

Weeks are worse

Months at least have unambiguous boundaries once you fix a timezone. Weeks do not.

Does the week start Sunday or Monday? Which week contains 1 January? ISO 8601 answers both — Monday, and the week containing the first Thursday — but plenty of code divides timestamps by 604,800 and calls the result a week number, which drifts from every calendar anyone uses.

If your analysis has weekly buckets, check what defines them. If you cannot tell, use months.

Hour-of-day is descriptive, not locational

Activity by hour is a legitimate thing to compute and the most over-read chart in this space.

The inference people reach for — a cluster of evening activity means the person lives in a particular timezone — does not hold. People travel, work nights, keep irregular hours, and schedule posts. And the sample is only what the archive captured and you loaded, so a gap may reflect collection rather than behaviour.

Compute it, label it UTC, and say plainly that it does not indicate location. A tool that offers "estimated timezone" has crossed from description into inference about a person, on evidence that does not support it.

Practical rules

Store UTC. Convert only at the edge. One conversion, at render time, is auditable. Conversions scattered through analysis code are not.

Record the timezone in exports. An exported chart of monthly activity means nothing without knowing how months were defined.

Keep retrieved_on. It is the only way to know whether a score is real.

Prefer coarse buckets when coverage is uneven. Yearly buckets tolerate gaps that daily buckets turn into apparent findings.

Do not infer a schedule. Timestamps show when records were captured. Why someone posted at a given hour is not in the data.

The general point

Timestamps are the field most likely to be handled casually, because they look simple. The errors they produce are quiet — no exception, no obviously wrong output, just a chart that would have looked different if someone else had run it.

Fixing the timezone at the analysis layer and converting only for display costs a few lines and removes an entire category of irreproducibility.