Does Google Maps store the real date behind 'a month ago'?

Google holds a precise timestamp internally, but the public review panel surfaces only the relative phrase. What a visitor, and therefore a browser exporter reading the same panel, can see is the rounded wording, not the exact date. That is the constraint any honest export has to work within.

Can an exporter recover the exact date?

Not from the relative phrase alone. 'A month ago' could be anywhere in a range of weeks, so the best any tool can do is compute an estimate and label it as approximate. A tool that shows you a precise calendar date for a review Google only dated as 'a month ago' has invented that precision, and you should not trust it.

How should I store these dates in a spreadsheet?

In two columns. Keep the exact phrase Google gave in one, so nothing is lost and you can always see the source, and put a labelled estimate in the other so you can sort and group. Collapsing them into a single fake-precise date throws away the honesty and gains you nothing analysis can rely on.

Does the estimate get better for recent reviews?

Yes. 'Three days ago' pins a review to a day; 'a year ago' spreads it across months. Estimates are tight for recent reviews and loose for old ones, which happens to match how much precision you usually need, since recent reviews are the ones worth placing on a timeline.

Google Maps Review Dates: Why 'a Month Ago' Is a Problem, and How to Handle It

If you have ever exported Google Maps reviews and tried to sort them by date, you have met the problem: the dates are not dates. They are phrases like “a month ago”, “2 weeks ago”, “a year ago”. A spreadsheet cannot sort those, a chart cannot plot them, and a naive tool will either drop them or, worse, make one up. This is a small problem that quietly ruins a lot of review analysis, so it is worth understanding properly.

What Google actually shows

Google Maps does not display a calendar date on a review. It displays a relative, rounded phrase: how long ago the review was posted, expressed in the largest convenient unit. “Yesterday”, “3 days ago”, “2 weeks ago”, “a month ago”, “a year ago”.

Google holds a precise timestamp for each review internally. But the public review panel, the thing a visitor sees and the thing a browser exporter reads, shows only the rounded phrase. Whatever you build on top of Google Maps reviews inherits that constraint. You are working with “a month ago”, not with 2026-06-14.

Why this breaks analysis

Relative dates fail the moment you want to do anything time-based:

You cannot sort them. “A month ago” and “2 weeks ago” do not order correctly as text, and a spreadsheet has no idea they are even dates.
You cannot group by period. “Reviews per month” is impossible when every date is a fuzzy phrase.
They rot. The phrase is relative to when it was captured. “A month ago”, exported today, means something different from “a month ago” exported next quarter. If you store the phrase alone, your data silently drifts out of date.

That last point is the subtle one. A column of relative phrases is not just hard to sort, it is actively misleading over time, because its meaning depends on a “now” that has moved on.

The wrong fix: inventing precision

The tempting fix is to convert “a month ago” into a real date and be done with it. Take the capture date, subtract a month, write 2026-06-24, move on.

This is worse than doing nothing, because it launders a rough guess into false precision. “A month ago” might be anywhere from three to six weeks. Writing an exact day implies you know something you do not, and anyone downstream who sees a clean calendar date will treat it as accurate. When they later correlate reviews against a product launch or an incident, they are correlating against fiction. A tool that shows you exact dates for relative phrases is not being helpful; it is hiding its own uncertainty from you.

The honest fix: two columns

The approach that actually works keeps both pieces of information and is honest about which is which.

Column one: the exact phrase. Store “a month ago” verbatim, plus the date you captured it. This is the ground truth. It never lies, and because you kept the capture date, “a month ago” stays interpretable no matter when you read the file.

Column two: a labelled estimate. Compute a best-effort calendar date from the phrase and the capture date, and mark the column clearly as approximate. Now you can sort, group and chart, while anyone reading the file can see at a glance that these are estimates, not Google’s own timestamps.

The estimate is naturally tighter for recent reviews and looser for old ones. “Three days ago” pins a review to a specific day. “A year ago” could be anywhere across a couple of months. That gradient is fine, because it matches how much precision you usually need: the recent reviews you actually want to place on a timeline are the ones the estimate handles well.

What to look for in a tool

When you evaluate a Google Maps exporter, this is a fast and revealing test. Export a place and look at the date columns.

If there is a single column of precise calendar dates, the tool is inventing precision. Be suspicious of everything else it produces.
If the relative phrase has been dropped entirely, you have lost the ground truth and cannot check the estimates.
If you see both the original phrase and a clearly-labelled estimate, the tool is being honest with you, which is the behaviour you want everywhere else too.

ExportReviews’s Google Maps exporter takes the two-column approach: the exact wording Google showed in one field, a labelled estimate in another. It is a small thing that tells you a lot about whether a tool respects the difference between what it knows and what it is guessing.

The takeaway

Relative dates are not a nuisance to paper over; they are a genuine limit of what Google Maps exposes, and the right response is to be honest about that limit rather than hide it. Keep the phrase, estimate alongside it, label the estimate. Any tool that does otherwise is trading your ability to trust the data for the cosmetic win of a tidy date column. For the rest of the export workflow, see the step-by-step guide.