Dates and Times

list.tdwg at ACHAPMAN.ORG list.tdwg at ACHAPMAN.ORG
Tue Feb 28 21:04:48 CET 2006


Philip and John have convinced me that it is better to use the start/end date/time approach rather than the mid-point and uncertainty approach.  Philip's arguments are very convincing.

Cheers

Arthur

>From Philip.Gleeson at environment.nsw.gov.au on 27 Feb 2006:

> I think the important point to remember in all of this is that time is
> linear and this allows for a simplified approach that is more difficult
> to apply in a 2-dimensional spatial situation. Where the boundaries of a
>
> time interval are known the two approaches are identical and require two
>
> data points to accurately specify the range. However, what of the
> situation where only one data point is known? It often occurs that one
> knows that a collection took place prior to a given date, or equally one
>
> may know that a collection occurred after a given date with no other
> information. This is easily catered for when a start and end datetime
> are
> used, but if a middle point and an accuracy have to be specified on an
> unbounded time interval, how do you do this? In contrast, I am not aware
>
> of any cases in collections where one has an accurate midpoint but is
> unsure of how far either side of this date the collection occurred. For
> this reason alone I would tend to lean towards the use of start and end
> dates over the alternative approach of a mid point and an accuracy as
> the
> latter can always be calculated from the former.
>
> Philip Gleeson
>
> Wildlife Data Officer
> Policy & Science Division
> Department of Environment & Conservation
> 43 Bridge St, Hurstville NSW 2220
> Ph: 9585 6694
>
>
>
>
> list.tdwg at ACHAPMAN.ORG
> Sent by: Taxonomic Databases Working Group List
> <TDWG at LISTSERV.NHM.KU.EDU>
> 28/02/06 18:12
> Please respond to list.tdwg
>
>
>         To:     TDWG at LISTSERV.NHM.KU.EDU
>         cc:
>         Subject:        Dates and Times
>
>
> 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 at 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 at 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
> >

=== message truncated ===




More information about the tdwg mailing list