Standards for date / time values?

Michael Lee mikelee at EMAIL.UNC.EDU
Mon Feb 27 10:58:54 CET 2006


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
want to make.  But an open field is problematic as you might not always be
able to interpret it.  Perhaps 2 fields: DateAccuracyNumeric and
DateAccuracyUnits would help, or you could require the units to be
converted to years, with very tiny accuracies being really small decimal
numbers.
4) Doesn't tackle issues of 2 dates (May or Sept of 1995) all that well.


But it seems flexible enough for our purposes.  I wasn't part of the team
that designed it, so I'm not sure what alternatives they considered and
for what reasons they rejected any alternatives they considered.

cheers,
michael


----------------------------
Michael Lee
VegBank Project Manager
http://www.vegbank.org
----------------------------

On Mon, 27 Feb 2006, Hannu Saarenmaa wrote:

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




More information about the tdwg mailing list