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)
|