1

I've run across an issue with date-time conventions in a file served via OPeNDAP. In particular this problem arises from the GrADS DODS Server (GDS). The GDS can serve files via reading a data descriptor (ascii file) that contains the specifics of the binary file (GDS is not limited to netCDF as input). The data descriptor file defines the start time and increment. Somehow, GDS converts this to a convention (?) of "days since 1-1-1 00:00:00". I've discovered an interesting issue with this.

As an example, the data served at http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily are defined to start on 03 March 2009. The OPeNDAP info page has the following for time:

time: Array of 64 bit Reals [time = 0..1141]

grads_dim: "t"
grads_mapping: "linear"
grads_size: "1142"
grads_min: "00z03mar2009"
grads_step: "1dy"
units: "days since 1-1-1 00:00:0.0"
long_name: "time"
minimum: "00z03mar2009"
maximum: "00z17apr2012"
resolution: 1.0

So it correctly gets the first time value. I've tested this in several client tools, including GrADS, Ferret, panoply, and IDV; all correctly recognize the first time value as March 3, 2009.

The trouble arises from the OPeNDAP time of "days since 1-1-1", which gets returned as 733470 (try an ncdump on the above file). As far as I can tell, this is actually March 5th, 2009. The result here is tools like Matlab and EDC get the initial date as March 5.

I'm wondering if anyone can shed some light on this? Thanks in advance,

Jim

JimP
  • 83
  • 5
  • Is it possible to work with the data provider to have a better time unit? It seems like the Unix epoch would be a better choice for satellite data from 2009. When you are dealing with time scales of ~2,000 years, what does it mean to have a 2 day discrepancy? – Julien Chastang Oct 08 '13 at 17:28
  • The problem is that it's really not 2,000 years worth of data, but the start time is referenced to 2,000 years ago. I believe this is done automatically by the OPeNDAP server (the input file has a start date of 03 March 2009). – JimP Oct 10 '13 at 01:12

2 Answers2

2

Unless the other tools use the 'minimum' attribute somehow, I cant see how the first time element can be 03-Mar-2009.

However, March 5th, 2009 checks out if use the information in the units field:

Here's what I see in MATLAB:

>> ncdisp('http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily','time')
Source:
           http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily
Format:
           64bit
Dimensions:
           time = 1142
Variables:
    time
           Size:       1142x1
           Dimensions: time
           Datatype:   double
           Attributes:
                       grads_dim     = 't'
                       grads_mapping = 'linear'
                       grads_size    = '1142'
                       grads_min     = '00z03mar2009'
                       grads_step    = '1dy'
                       units         = 'days since 1-1-1 00:00:0.0'
                       long_name     = 'time'
                       minimum       = '00z03mar2009'
                       maximum       = '00z17apr2012'
                       resolution    = 1

Lets see what MATLAB's reference date is for numbers:

matlabRefDate = datestr(0)

matlabRefDate =

00-Jan-0000

The date number for this data source is since 1-1-1 so:

dataRefDate = '01-Jan-0001'; dataRefDateNum = datenum(dataRefDate)

dataRefDateNum =

   367

Lets read the data and update the reference:

>> time = ncread('http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily','time');
>> datestr(time(1))

ans =

03-Mar-2008

>> correctedTime = time+dataRefDateNum;
>> datestr(correctedTime(1))

ans =

05-Mar-2009
Ashish Uthama
  • 1,331
  • 1
  • 9
  • 14
1

I think I may have found the explanation:

From http://aa.usno.navy.mil/data/docs/JulianDate.php

The Julian date for CE 2009 March 3 00:00:00.0 UT is JD 2454893.500000

The Julian date for CE 1 January 1 00:00:00.0 UT is JD 1721423.500000

So the time of the ASCAT start since the year 1 origin is 733470 days. This agrees with the GrADS/GDS accounting. The answer all comes down to reference dates. I suspect that what netCDF4 calls the "standard" calendar is this USNO version that switches from Gregorian to Julian, and this is not what matlab does.

It's probably better practice, therefore, not to reference to Jan 1, 0001 but rather something closer to present thus avoiding the potential two day difference between old and new calendars. However, if a data service is providing it (as is the case here), you're kind of stuck with it.

Eric Firing has a nice summary here:

http://matplotlib.org/api/dates_api.html

JimP
  • 83
  • 5