[Top] [All Lists]

Re: [ontolog-forum] Time representation

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, 22 Jan 2008 12:02:38 -0500
Message-id: <479621AE.6070806@xxxxxxxx>
John Sowa wrote:    (01)

>> There are so many hard problems, it's hard to say which are harder.
>> But the idea of taking the least significant digit as the criterion
>> for implicit granularity is fairly common for experimental data
>> (unless some explicit margin of error is stated).    (02)

With my NIST hat firmly on, I would say that in John's parenthetical 
addendum he hit on a critical issue.  Most identifications of "points in 
time" are inaccurate, and the stated precision probably isn't the 
intended accuracy.  For example, is 21 January 2008 at midnight really 
accurate to the second, just because it was captured as:
   "20080121T000000 +0500" (ISO 8601 form)?    (03)

Certain carefully stated scientific measures of time, e.g. astronomical 
observations or standard time dissemination, are intended to be accurate 
and have a stated accuracy (margin of error/uncertainty), because they 
need to be compared with times observed for other events by other 
unknown observers.  But most times are intended to be used only in 
comparison with other events observed by some particular community of 
observers.    (04)

Computer clocks, in particular, may give precision to milliseconds and 
still be minutes off the standard time.  If my laptop computer 
timestamps an event with the time given above, that is probably plus or 
minus 3 minutes from Eastern Standard Time as disseminated by NIST, or 
5:00 A.M. as disseminated by the Greenwich Observatory.  (Now, as it 
happens, my desktop computer time is synchronized once a day with the 
disseminated standard time, but even so, it is probably wrong 8 hours 
later, even if only by a second or two.)  The computer timestamps are 
still valid for precise comparisons between times of events on that 
computer, but they are not necessarily valid for comparison with events 
timed by some other computer.    (05)

So when we talk about converting between time granularities, we have to 
talk about the intent of the conversion relative to the communities 
involved.  If you take two times out of the context of use, you are 
comparing apples and oranges.  You can get away with it, as long as the 
interpreted timestamps don't have overlapping domains of uncertainty, 
but since you don't know what those are, you are using some kind of 
seat-of-the-pants statistics to judge the probable value of the 
comparison.  To use a particularly apt metaphor, it is a lousy way to 
run a railroad.*    (06)

Matt West says:    (07)

> And what they really are, i.e. in this case an interval or period. Now 
> there is, in my mind, nothing wrong with naming an interval 14th Jan
> 2008, but it needs to be understood that it has a start time of midnight
> at the start of the day, and an end time of midnight at the end of the
> day, and that it is not in any sense a point in time.    (08)

The problem is that it is the designation for a precise "point in time" 
in some frame of reference, and a rough designation for an "interval" in 
another frame of reference.  And because it is a rough designation (your 
midnight and my midnight are not necessarily the same UTC instant), any 
comparison that is close to the interval boundary, which is a nominally 
more accurate point in time, has some margin for error within which the 
relative time relationship is *indeterminate*.  As Matt says:    (09)

> All this for me is independent of whether time is ultimately granular
> or continuous. Ultimately this only means at what point we can not longer
> tell whether one event happened before another.    (010)

Exactly.  But the problem is that we don't know what the intended 
accuracy of most timestamps is.  If we leave it to software, or lawyers 
(or logicians, if this thread is any indication), we will get 
hard-and-fast uneducated decisions near the boundaries.  IMO, one cannot 
compare timestamps from different sources without understanding the 
overall margin of error in the clocks, and one cannot compare timestamps 
with different granularities without understanding the intent of the 
comparison.    (011)

-Ed    (012)

*The original motivation for standard time in the United States was to 
get railroad schedules to make sense.  Theretofore, time at a place was 
referenced to a particular clock that was adjusted to "sun time" at that 
place every noon.    (013)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (014)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (015)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (016)

<Prev in Thread] Current Thread [Next in Thread>