<p>Attached is patch to extend RPMTAG_{BUILDTIME,INSTALLTIME,INSTALLTID} to add a 2nd element that contains a struct timespec tspec.tv_nsec 2nd element.</p>
<p>There are 2 new getters/setters added to the rpmts API: rpm{Get,Set}Tid2().</p>
<p>About the only subtlety (so far) is the need (for rpmdb "legacy compatibility") to index only tspec.tv_secs in RPMDBI_INSTALLTID. A better index could be attempted, but the value of the Installed index w/o --rollback is questionable. Using a UUIDv1 timestamp would be one possible choice for a more precise RPMDBI_INSTALLTID key.</p>
<p>These are the reasons (that I know of) to increase the precision of time stamps:</p>
<ol start="0">
<li>
<p>time(2) is very last century (but still doing the job).</p>
</li>
<li>
<p>INSTALLTIME can be inaccurate these days: fast processors can install multiple packages/second.</p>
</li>
<li>
<p>INSTALLTID was designed to be unique: adding microsecs/nanosecs helps ensure the uniqueness.</p>
</li>
<li>
<p>UUIDv1 time stamps are likelier to be unique if generated with a high precision time stamp.</p>
</li>
</ol>
<p><a href="https://github.com/rpm-software-management/rpm/files/912203/rpm.tstamp.patch.gz">rpm+tstamp.patch.gz</a></p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/197#issuecomment-293156091">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb80_SBJV9KIG9rqDrhNMNFop2bsSmKks5ruxNGgaJpZM4M4QiX">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb80yY0mht2brk1AhzabYN2KFp3ATF-ks5ruxNGgaJpZM4M4QiX.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/197#issuecomment-293156091"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #197: Attached is patch to extend RPMTAG_{BUILDTIME,INSTALLTIME,INSTALLTID} to add a 2nd element that contains a struct timespec tspec.tv_nsec 2nd element.\r\n\r\nThere are 2 new getters/setters added to the rpmts API: rpm{Get,Set}Tid2().\r\n\r\nAbout the only subtlety (so far) is the need (for rpmdb \"legacy compatibility\") to index only tspec.tv_secs in RPMDBI_INSTALLTID. A better index could be attempted, but the value of the Installed index w/o --rollback is questionable. Using a UUIDv1 timestamp would be one possible choice for a more precise RPMDBI_INSTALLTID key.\r\n\r\nThese are the reasons (that I know of) to increase the precision of time stamps:\r\n\r\n0) time(2) is very last century (but still doing the job).\r\n\r\n1) INSTALLTIME can be inaccurate these days: fast processors can install multiple packages/second.\r\n\r\n2) INSTALLTID was designed to be unique: adding microsecs/nanosecs helps ensure the uniqueness.\r\n\r\n3) UUIDv1 time stamps are likelier to be unique if generated with a high precision time stamp.\r\n\r\n[rpm+tstamp.patch.gz](https://github.com/rpm-software-management/rpm/files/912203/rpm.tstamp.patch.gz)\r\n"}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/197#issuecomment-293156091"}}}</script>