<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Importance of Time</title>
	<atom:link href="http://lidarnews.com/the-importance-of-time/feed" rel="self" type="application/rss+xml" />
	<link>http://lidarnews.com/the-importance-of-time</link>
	<description>Laser Scanning Industry News</description>
	<lastBuildDate>Fri, 19 Mar 2010 09:13:12 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Gene V. Roe</title>
		<link>http://lidarnews.com/the-importance-of-time/comment-page-1#comment-364</link>
		<dc:creator>Gene V. Roe</dc:creator>
		<pubDate>Sun, 05 Jul 2009 15:17:11 +0000</pubDate>
		<guid isPermaLink="false">http://lidarnews.com/?p=1091#comment-364</guid>
		<description>Thanks for the perspective.

Gene</description>
		<content:encoded><![CDATA[<p>Thanks for the perspective.</p>
<p>Gene</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Allen</title>
		<link>http://lidarnews.com/the-importance-of-time/comment-page-1#comment-363</link>
		<dc:creator>Steve Allen</dc:creator>
		<pubDate>Sat, 04 Jul 2009 17:46:09 +0000</pubDate>
		<guid isPermaLink="false">http://lidarnews.com/?p=1091#comment-363</guid>
		<description>It is not possible to be accurate (to the nanosecond), broad, and simple.
Time is not something that can be known, it must be measured by someone and then provided to something.  It&#039;s a process, and it&#039;s a process which always has lookup tables.

In order to agree on time (within the bounds that relativity allows, and for moving detectors that may be relevant to consider as well) it must be obtained from a known source which is comparing itself with other known sources and publishing ex post facto tables of corrections to the time which it was providing.

There is no source for TAI, it is not available until next month, and BIPM itself will recommend not using it.

UTC is available, but its definition is subject to an international committee who are not in consensus about whether it should change its characteristics.  Whether or not UTC has leap seconds in the future, it has already had them, so they must be addressed.  Also, UTC from one source is not the same as UTC from another source, thus the BIPM publishes Circular T every month, a table of differences which must be applied.

GPS time is under the control of US DoD, USNO, and (even though it is unlikely to change its characteristics at the microsecond level) as such is not palatable for international standards committees.  At the microsecond level it is effectively the same as TAI, but at the nanosecond level there are, as with all time scales, lookup tables which must be applied to get agreement.  Beyond that, the quality of the individual GPS receivers varies considerably at the sub-microsecond level, and nanosecond precision might require documenting the hardware and software in use during a measurement.

This is an engineering decision which has to conform itself to the available (and subject to change) standards and services.  Good luck.</description>
		<content:encoded><![CDATA[<p>It is not possible to be accurate (to the nanosecond), broad, and simple.<br />
Time is not something that can be known, it must be measured by someone and then provided to something.  It&#8217;s a process, and it&#8217;s a process which always has lookup tables.</p>
<p>In order to agree on time (within the bounds that relativity allows, and for moving detectors that may be relevant to consider as well) it must be obtained from a known source which is comparing itself with other known sources and publishing ex post facto tables of corrections to the time which it was providing.</p>
<p>There is no source for TAI, it is not available until next month, and BIPM itself will recommend not using it.</p>
<p>UTC is available, but its definition is subject to an international committee who are not in consensus about whether it should change its characteristics.  Whether or not UTC has leap seconds in the future, it has already had them, so they must be addressed.  Also, UTC from one source is not the same as UTC from another source, thus the BIPM publishes Circular T every month, a table of differences which must be applied.</p>
<p>GPS time is under the control of US DoD, USNO, and (even though it is unlikely to change its characteristics at the microsecond level) as such is not palatable for international standards committees.  At the microsecond level it is effectively the same as TAI, but at the nanosecond level there are, as with all time scales, lookup tables which must be applied to get agreement.  Beyond that, the quality of the individual GPS receivers varies considerably at the sub-microsecond level, and nanosecond precision might require documenting the hardware and software in use during a measurement.</p>
<p>This is an engineering decision which has to conform itself to the available (and subject to change) standards and services.  Good luck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gene V. Roe</title>
		<link>http://lidarnews.com/the-importance-of-time/comment-page-1#comment-362</link>
		<dc:creator>Gene V. Roe</dc:creator>
		<pubDate>Thu, 02 Jul 2009 21:39:18 +0000</pubDate>
		<guid isPermaLink="false">http://lidarnews.com/?p=1091#comment-362</guid>
		<description>Thanks for the info.

Gene</description>
		<content:encoded><![CDATA[<p>Thanks for the info.</p>
<p>Gene</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: orcmid</title>
		<link>http://lidarnews.com/the-importance-of-time/comment-page-1#comment-361</link>
		<dc:creator>orcmid</dc:creator>
		<pubDate>Thu, 02 Jul 2009 19:01:32 +0000</pubDate>
		<guid isPermaLink="false">http://lidarnews.com/?p=1091#comment-361</guid>
		<description>I am surprised that you haven&#039;t looked at ISO 8601 and all the related IETF specifications on reporting and reconciling date-time.  The same problems arise on the Internet at various levels and even in productivity software (e.g., the ODF and OOXML formats).  

I believe there are various pitches on how to deal with leap seconds too, although astronomers and aerospace folks may be a better source if to-the-second time-interval determinations are significant.</description>
		<content:encoded><![CDATA[<p>I am surprised that you haven&#8217;t looked at ISO 8601 and all the related IETF specifications on reporting and reconciling date-time.  The same problems arise on the Internet at various levels and even in productivity software (e.g., the ODF and OOXML formats).  </p>
<p>I believe there are various pitches on how to deal with leap seconds too, although astronomers and aerospace folks may be a better source if to-the-second time-interval determinations are significant.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
