4 ms·

Public Service Announcement: Use UTC. http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html http://yellerapp.com/posts/2015-01-12-the

• masklinn 11y ago
  The script just seems to assume whichever date is in the mtime field is a local time.
  • Piskvorrr 11y ago
    Exactly. So, if every server (or a significant fraction) reports in UTC, the heuristic is no longer reliable.
    • masklinn 11y ago
      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.
      • brlewis 11y ago
        It would appear 2 of the 3 examples he gives at the end of the article are returning UTC. Only Bing returns Pacific Time.
• briankwest 11y ago
  Came here to say exactly this!
• api 11y ago
  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.
  • rtkwe 11y ago
    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.