I always always always write code to just use the numeric time in seconds or milliseconds since the epoch. Time is only converted into messy Gregorian cruft to display to the user. Anything else is begging for crazy bugs.
In a SQL database a time field should be an unsigned bigint.
While that works it'd be a real annoyance to deal with when doing a lot of the debugging queries I wind up writing for work doing batch ETL. As far as I have found there's no built in function that would take that epoch timestamp and convert it into a usable date that could then be truncated for daily binning etc.
The script just seems to assume whichever date is in the mtime field is a local time.
Exactly. So, if every server (or a significant fraction) reports in UTC, the heuristic is no longer reliable.
Which could already be the case, spec-wise the gzip timestamp is supposed to be POSIX time, which is in UTC and provides no timezone information.
It would appear 2 of the 3 examples he gives at the end of the article are returning UTC. Only Bing returns Pacific Time.