Dear all,
in our work, we have often been confronted with the current limitations
where the only times allowed by CF are "real" times using the "days since date"
syntax and assuming the Gregorian calendar. We often have "climatological"
fields as model input data, where monthly variation is
On 3/17/11 5:20 PM, John Caron wrote:
On 3/17/2011 12:19 PM, Steve Hankin wrote:
in "dimensional units", "secs" is a base dimensional unit, and it means
"duration", eg watts = joules/sec, the sec is a time duration, not an
instant of time.
"time" is not a dimensional unit, it refers to a poin
Martin,
On 03/18/2011 04:11 AM, Schultz, Martin wrote:
> PS: I do disagree with Christopher when he says ''"30 days since 31 Jan 2008"
> is perfectly well defined.'' - do you refer to 00 UTC or 12 UTC on 31 Jan
> 2008? Or even 00:00 UTC or 01:02:30.3625132 h UTC? OK: if you define an
> "oceanog
> Just so you know, the UDUNITS package does assume the first day of the
> year at 00:00:00 UTC if additional resolution time-fields are omitted.
> This conforms to the ISO standard.
Actually (according to Wikipedia at least) the ISO8601 standard assumes local
time if the time zone is omitted. I
It is worse than that -- though the local time of the standard creates a
problem for us -- according to the iso standard, if time is omitted, the
string corresponds to the whole day, not the start of the day -- ISO8601 is
a time *interval* standard -- the iso8601 string implies a moment and a
width
On 3/18/11 10:23 AM, Jon Blower wrote:
Just so you know, the UDUNITS package does assume the first day of the
year at 00:00:00 UTC if additional resolution time-fields are omitted.
This conforms to the ISO standard.
Actually (according to Wikipedia at least) the ISO8601 standard assumes local
hmm, where do you see that part about "the iso8601 string implies a
moment and a width a.k.a resolution". i was reading it that the duration
= width spec was separate.
in any case, this probably highlights the need to be specific about what
CF semantics are.
On 3/18/2011 12:27 PM, Benno Blum
Quoting from
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
which says things like
*Example: *2003-04-01 represents the first day of April in 2003.
*Example:* 2003-04-01T13:01:02 represents one minute and two seconds after
one
On 3/17/2011 10:50 AM, Christopher Barker wrote:
2. calendar time
- calendar time representation needs to be clarified
- udunits should no longer be the reference library for calendar time. a
new reference library is needed, which handles non-standard calendars.
again, the lib is not the p
On 3/18/2011 4:11 AM, Schultz, Martin wrote:
Dear all,
in our work, we have often been confronted with the current limitations where the only times allowed by
CF are "real" times using the "days since date" syntax and assuming the Gregorian
calendar. We often have "climatological" fields
On 3/18/2011 9:17 AM, Bob Simons wrote:
On 3/17/2011 5:20 PM, cf-metadata-requ...@cgd.ucar.edu wrote:
From my POV, the problem is that users need more expressiveness
for the
calendar time. I certainly do. For yearly data, "years since base_date
by calendar field" (or whatever) is consistent,
On 3/18/2011 10:21 AM, Christopher Barker wrote:
John -- I'm wondering if you have any idea about what the API of a
reference lib should look like? If a time axis is defines as:
"calendar months since January, 2008", what sort of functions do you
image would exist to deal with that?
i am wo
On 3/18/11 12:21 PM, John Caron wrote:
CF has the calendar attribute (see section 4.4.1)
and thanks for posting that -- so that's taken care of.
well, plenty of algorithms just want, say, the monthly average. but if
you want to know the exact time interval, you need a library that deals
with
13 matches
Mail list logo
