As a unabashed proponent of the Point-Radius Method I have to confess that I was tempted to try exactly what Arthur is proposing here, and for the same reason - a consistent way of dealing with uncertain measures. But I didn't like the result. The basic reason is that the single date value plus duration (before and after) can't capture the situation where the uncertainties on the two ends of the duration differ. In other words, it can't capture "definitely before midnight local time, 2 May 2000."

 
On 2/27/06, list.tdwg@achapman.org <list.tdwg@achapman.org> wrote:
This is an interesting discussion, and I am wondering why we treat dates/times differently to localities where we may have "between two places", "near a place", "along a path", etc.

At this stage, we tend to recommend using a single location (lat/long) with an uncertainty surrounding that location.  With location, we are currently using a circle to determine the uncertainty in a locality, where as time is linear (and thus easier). We may change to the use of polygons and uncertainty footprints at a later stage but let's leave that discussion for another time.

Would not the better way to handle some of these data/time situations be to use a midpoint with an uncertainty.  Thus for "01-2000" we should not interpret that as 01-01-2000 but as 15-01-2000 with an uncertainty of 15 (or 16) days - can be refined with the incorporation of time.  This is, of course, not all that dis-similar to what michael is suggesting.

On a related issue - if we have two dates - the dates may be "accurately" determined - but the actual time of occurrence is uncertain.  I thus prefer the use of the term uncertainty - and possibly better (as we will most likely use in the Georeferencing Best Practices document under preparation) - "Maximum Uncertainty" or perhaps "Maximum uncertainty estimate"

Perhaps there are good reasons for using start and end dates/times - if so I am happy to go along with that - but believe we should aim for consistency of approach if possible.

Cheers

Arthur

Arthur D. Chapman
Australian Biodiversity Information Services
Toowoomba, Australia

From Automatic digest processor <LISTSERV@LISTSERV.NHM.KU.EDU> on 27 Feb 2006:

> There are 3 messages totalling 562 lines in this issue.
>
> Topics of the day:
>
>   1. Standards for date / time values? (3)
>
> ----------------------------------------------------------------------
>
> Date:    Mon, 27 Feb 2006 12:27:23 +0100
> From:    Hannu Saarenmaa <hsaarenmaa@GBIF.ORG>
> Subject: Re: Standards for date / time values?
>
> In my understanding the "Not interpreted" case would be just a text
> string "DateTimeSourceText", repeating whatever is written in the label
> about the dates and times.  This can be useful if questions arise of the
> interpretation.
>
> Btw., isn't he name of the element "EarliestDateCollected" in Darwin
> Core v.1.4 proposal a bit misleading as it really is
> "EarliestDateTimeCollected"?
>
> Hannu
>
> Richard Pyle wrote:
>
> >RE: CollectingDatesInterpreted
> >When would this field *not* be set to true?
> >
>
> ------------------------------
>
> Date:    Mon, 27 Feb 2006 10:58:54 -0500
> From:    Michael Lee <mikelee@EMAIL.UNC.EDU>
> Subject: Re: Standards for date / time values?
>
> Hello all,
>
> It seems to me that the VerbatimDate/EarliestDate/LatestDate are
> helpful, but combine two separate issues:
>
> 1) duration of the event spanning more than one date/time unit
> 2) error associated with the date.
>
> Is the distinction useful?  Probably depends on your application of the
> date.
>
> To handle these, VegBank uses three fields:
>
> startDateTime
> stopDateTime
> dateTimeAccuracy
> (note that there is NO verbatimDate)
>
> StartDateTime is most precise known date/time for the beginning of an
> event (in our case an observation of a vegetation plot) and the
> EndDateTime is the end date/time (which could have the same value).
> DateTimeAccuracy is a string with a list of values ranging from 1 second
> to 1 day to 1 year to 5,10 years, etc.
>
> start and stop deal with issue #1 above, duration (potentially)
> exceeding
> usual date description precision.
>
> The accuracy field deals with isue #2 above, error or uncertainty
> regarding the dates.  It is this accuracy field that seems to be missing
> from this discussion thus far.
>
> As far as time zones go, error on the order of hours isn't TOO important
> to us, so we don't worry about it too much.  But I think what we're
> aiming
> to do is to store the date/time according to UTC.  This means that to
> reconstruct what time the person saw something, the original time zone
> and
> Daylight Savings Time would need to be known, but this isn't crucial to
> us, either.
>
> I like Lynn's list of weird dates, so I'll throw in what we'd do with
> them
> (this of course being "interpreted" but as Rich says, that's almost
> always
> the case):
>
> PRE-1975
>   Start:null ; End: 01-JAN-1975 ; Accuracy: null or possibly a large
> value
> post-1992
>   Start: 01-Jan-1992; End:null ; Accuracy: null or possibly a large
> value
> summer 2001
>   Start: 15-JUL-2001; End:15-JUL-2001 ; Accuracy: 1.5 months
> Mid-1990s
>   Start: 01-JUL-1995; End: 01-JUL-1995 ; Accuracy: 2 years
> late 1950's
>   Start: 01-JAN-1958; End: 01-JAN-1958; Accuracy: 2.5 years
> Circa 1941
>   Start: 01-JUL-1941; End:01-JUL-1941; Accuracy: 6 months
> Early 1990s
>   Start: 01-JAN-1992; End:01-JAN-1992; Accuracy: 2 years
>
> Except for the "pre-Date" and "post-Date" I have assumed a relatively
> short duration.  But this is interpreted.  The problems with this
> approach
> I see are:
> 1) accuracy for start and stop dates could be different
> 2) accuracy is not a black and white idea.  It's often more of a
> gradient. Seems
> illogical to specify 10 years as accuracy in the first 2 examples, as
> the
> dates could be much more than 10 years away.
> 3) a closed list on accuracy seems to force you into decisions you don't

=== message truncated ===