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(a)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(a)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(a)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 ===
