[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #NPU-258487]: 9 of 12 featureCollections failing after upgrade from 4.2 to 4.3

Hi all: responses are embedded

> Lansing,
> 
> We are talking about CF time conventions, right?
> 
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch04s04.html
> 
> The CF specification says:
> "
> seconds since 1992-10-8 15:15:42.5 -6:00
> 
> indicates seconds since October 8th, 1992  at  3  hours,  15
> minutes  and  42.5 seconds in the afternoon in the time zone
> which is six hours to the west of Coordinated Universal Time
> (i.e.  Mountain Daylight Time).  The time zone specification
> can also be written without a colon using one or  two-digits
> (indicating hours) or three or four digits (indicating hours
> and minutes)."
> 
> but it doesn't say anything about only one space being allowed.

the udunits specification is notoriously vague about what date formats are 
allowed. 
there is no grammar specified; you might imagine you could put the word 
"elephant"
between the date and time also ;^)

anyway, we dont use udunits anymore for that and other reasons. the new spec is 
here:

http://www.unidata.ucar.edu/software/thredds/v4.4/netcdf-java/CDM/CalendarDateTime.html

> 
> I realize (now) that TDS abandoned udunits for time handling in TDS
> 4.3, but it seems to me that datasets in which time was handled
> correctly in TDS 4.2  should not break in TDS 4.3.
> 
> Don't you agree?
> 
> And I don't see how allowing multiple white space instead of one white
> space is a slippery slope.

its a reasonable argument, but there are limits. since theres no udunit grammar,
we dont know in any formal way what udunits allows, we are just dealing with 
these
edge cases one by one.

if this is a big problem, we can allow extra white space, although we wont 
change the official spec.
if its just a few place, might be better to fix them.
how extensive is the problem, do you know? 

> 
> -Rich
> 
> P.S. Just as an aside, I thought ISO 8601 time was represented without
> any spaces, like:
> 
> 2001-02-03T09:30:01
> 2004-01-01T10:10:10Z
> 2004-01-01T10:10:10+05:00
> 
> Can you provide the URL that says ISO 8601 time can be specified using
> a separator of one space and one space only?

ISO 8601 only allows a 'T' (reference in link above). we allow the ' ' for 
udunit compliance, also i find it a bit more reabable. 
really, i just never thought of the multiple space possibility.

John


Ticket Details
===================
Ticket ID: NPU-258487
Department: Support THREDDS
Priority: High
Status: Open