Standards Gang,

Some background materials for the PDS Standards telecon on Wednesday:

Chronology
==========

Several years ago our attention was drawn to time standards for a reason I 
no longer remember.  This led to discussions about time zone indicators, 
whether the "Z" should be required, optional, or barred from PDS time 
elements, allowable date and time formats, and so on.

The original SCR (3-1019) was one of several submitted around the same 
time. This one addresses the issue that there is no declared reference 
frame in the PDS for the principal *_TIME elements - most notably 
START_TIME and STOP_TIME.  The original SCR proposed that a time standard 
be declared in the definition of each of the *_TIME elements in the data 
dictionary.

Discussion
==========

There are, in fact, 64 TIME elements (i.e., elements with the word "TIME" 
in them) in the latest version of the pdsdd.full file.  Looking down the 
list, I see such diverse elements as:

  EARTH_RECEIVED_TIME
  EFFECTIVE_TIME
  LOCAL_TIME
  MAXIMUM_LOCAL_TIME
  NATIVE_START_TIME
  NOTEBOOK_ENTRY_TIME
  PRODUCT_CREATION_TIME
  START_TIME
  etc.

In many cases it is not immediately clear to me that UTC is the correct or 
natural time system for the keyword, and I can see a possibility for 
endless discussions about what should be allowed or prohibited.  I'm not 
sure it's worth the effort to try to deal with every one of them 
individually, and I don't think there is any reasonable blanket solution.

I think the single biggest problem - perhaps the only problem worth arguing 
about - is the lack of a standard for START_TIME and STOP_TIME, since these 
are part of that small set of nearly universal elements that appear in all 
data file labels.  I think it is also true the UTC is the standard time 
system for astronomical observations.  So I would hope that it would be a 
relatively easy thing to agree that START_TIME and STOP_TIME must be in 
UTC.  Here's the current definition of START_TIME:

     The start_time element provides the date and time of
     the beginning of an event or observation (whether it
     be a spacecraft, ground-based, or system event) in
     UTC system format.
     Formation rule: YYYY-MM-DDThh:mm:ss[.fff]"

The problem in this definition is only the phrase "UTC system format". 
"Format" implies that this is just a display convention, and there really 
isn't any such thing as a "UTC format".  In fact, START_TIME and STOP_TIME 
must be given in a format compliant with the ISO 8601 standard, which is 
what the formation rule implies.  (It is a subset of the ISO 8601 formats.) 
But a display format standard is not a measurement standard, so the 
definition as stated above still doesn't actually require that START_TIME 
be stated in UTC.

I would hope that the vast majority of data sets in the current archive do, 
in fact, use UTC as the time standard for START_TIME and STOP_TIME. And in 
those cases where UTC is not used, I would guess that it doesn't materially 
affect interpretation of the data.  So declaring UTC as the time standard 
for these keywords shouldn't be a major disruption for existing data or 
data currently in preparation.


Recommendations
===============

o  START_TIME and STOP_TIME should have their PSDD definitions modified to
   state explicitly that they are measured in UTC.  I'd call this high 
   priority largely because a) it should be relatively simple to do, provided
   we agree, and b) with increasing national exposure and interoperability
   discussions with NVO heating up, it would be rather embarrassing to have
   to admit that we don't actually have a time standard for START_TIME.

o  References in other PSDD definitions to "UTC system format" (there 
   are about 18 of these) should be modified to indicate either UTC (for 
   measurement) or the ISO 8601 format for display, or both, depending on 
   what was intended.  This I think I would classify as medium priority.  
   It's largely accounting, but it needs to be done carefully, and these 
   other keywords are not quite so exposed to public scrutiny as 
   START/STOP_TIME are.

-Anne.