Re: 980129: Year 2000 Compliance part II

>To: address@hidden
>From: Carl Crites <address@hidden>
>Subject: Year 2000 Compliance part II
>Organization: The University of Oklahoma
>Keywords: 199801292146.OAA16648

Hi Carl,

> The University of Oklahoma is currently conducting a Year 2000 audit of
> all software, hardware, and elctronic equipment on campus.  In order to
> complete the audit we need information about the readiness of your
> products.  We need specific product information about the readiness of
> your products.  We need specific product year 2000 readiness information
> on:
> 
> NetCDF
> 
> We have adopted the following definition of Year 2000 ready:  "Ready"
> means that when used in accordance with its associated documentation, it
> is capable of correctly processing, providing and/or receiving date data
> within and between the twentieth and twenty-first centuries, provided
> that all products (for example, hardware, software, and firmware) used
> with the product properly exchange accurate date data with it.
> 
> Please provide us with a list of all versions/releases of the roducts
> listed that meet the above definition of compliance, avaliability dates
> of the compliant releases, and any prerequisite software and/or
> maintenance that may be compliant releases, and any prerequisite
> software and/or mainenance that may be required to install these
> releases.  if any of your products will not complly with this
> definition, please provide a detailed statement of any defiations that
> may exist.
> 
> Sincerely,
> 
> Carl Crites
> Year 2000 Project Manager
> The University of Oklahoma

All versions/releases of netCDF are Year 2000 ready, because none of the
netCDF libraries or programs deal in any special way with dates as a
data type.  If users want to represent date or time data in a netCDF
file, they may choose their own convention for such representation in
terms of basic data types such as integers, floating point numbers, or
character strings.  For example, some users archive data in terms of
double-precision floating point numbers, representing "seconds since
1970-1-1 00:00 UTC".  Year-2000 compliance issues are entirely the
responsibility of the netCDF data provider, not the netCDF library,
which only deals with arrays of fundamental data types.

I've appended more information on our recommendations for representing
time in netCDF files, in case you're interested.

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu

    We have sought ways to represent time that require neither multiple
    numbers nor character strings for each time value.

    Our solution exploits: 1) the netCDF capability for assigning a unit
    of measure to each variable, in the form of an attribute, and 2) a
    nice units conversion package, udunits, which is available as a
    companion to the netCDF library. Units of measure are character
    strings which adhere to the (rather flexible) grammar employed in
    udunits; when units of measure are conformable, udunits may be used
    to determine the relationships between them and perform
    conversions. Critical to this discussion is the fact that a units
    descriptor string may contain an origin. The following example is
    taken from the NetCDF Users Guide:

    time:units = "hours since 1990-11-25 12:00 UTC";

    Another example, which corresponds precisely to the standard measure
    of time in UNIX systems, is:

    time:units = "seconds since 1970-1-1";

    Similarly, the units may be in years, days, nanoseconds, and so
    forth.  With this mechanism, one can store time values in
    conventional numerical formats (integer, real, double, etc.) and
    meet any accuracy requirement we can envision. For more detail,
    please see the udunits documentation.

    Thus, the Unidata recommendations for representing time values in
    netCDF files are:

    * Store time values in numerically typed variables (not attributes).

    * Assign each such variable its proper unit of measure and origin by 
      using the associated "units" attribute.

    * Values assigned to these "units" attributes should be interpretable
      by the udunits package.