On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch <n...@leadboat.com> wrote: >> That brings it back to the enforcing - would we want to enforce both those? > > May as well. AuthorDate is the main source of trouble. You would need to go > out of your way (e.g. git filter-branch) to push an old CommitDate, but let's > check it just the same.
Actually, you just need the system clock to be off. I've noticed, for example, that when my VMware VMs go to sleep (because I close my laptop lid) their clocks don't run, so I have to remember to ntpdate afterwards if I want correct time. I don't happen to use those for committing to PostgreSQL, but somebody else might have a similar setup that they do use for that purpose. So +1 for sanity-checking the commit date, and +1 as well as Alvaro's proposal for checking for both past and future times. I think we should tolerate a bit more in terms of past timestamps than future timestamps. It's quite reasonable for someone to commit locally and then run make check-world or so before pushing; let's not make that unnecessarily annoying. But future timestamps should really only ever happen because of clock slew, and I don't think we need to tolerate very much of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
