On 3/30/2013 11:08 PM, John Graybeal wrote:
On Mar 28, 2013, at 22:23, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
If it's not going to be used as the time coordinate, then we don't need a
standard_name or unit for it, as you don't need libraries to be able to
universally
On Mar 28, 2013, at 22:23, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
If it's not going to be used as the time coordinate, then we don't need a
standard_name or unit for it, as you don't need libraries to be able to
universally auto-detect it and be able to compute with it.
On Mar 28, 2013, at 17:54, Steve Hankin steven.c.han...@noaa.gov wrote:
netCDF files are in every sense binary files. They cannot be read except
by custom-built utilities. (Or is there a constituency that wants to access
CF using the unix strings command?) In all cases except the present
CF does support using ASCII strings for enumerated lists of named
objects: PI name, ship names, species names, etc. An important
encoding ability. That capability is not in question.
- Steve
On 3/28/2013 9:36 AM, John Graybeal wrote:
On Mar 28, 2013, at 17:54, Steve Hankin
On Thu, 28 Mar 2013 09:22:57 -0400
Aleksandar Jelenak - NOAA Affiliate aleksandar.jele...@noaa.gov wrote:
On Fri, Mar 22, 2013 at 4:31 PM, Seth McGinnis mcgin...@ucar.edu wrote:
Maybe I'll change my mind after the community has made the jump to
netcdf4
Dear Seth,
What benchmark do you suggest
On Thu, Mar 28, 2013 at 7:49 AM, Jim Biard jim.bi...@noaa.gov wrote:
It seems to me that we are trying to figure out how to denote that a
variable contains a non-arithmetic expression of time, similar to degree
minute second hemisphere representations of latitude and longitude.
My question was, Is that all it supports ASCII strings for? (Not meant to be a
loaded question, but it seems to be at the heart of the discussion and opinions
expressed.)
John
On Mar 28, 2013, at 18:56, Steve Hankin steven.c.han...@noaa.gov wrote:
CF does support using ASCII strings for
Hi Steve,
On Wed, Mar 27, 2013 at 11:05 AM, Steve Hankin steven.c.han...@noaa.gov wrote:
I think we're talking about different issues. The thought question I posed
was not whether it is acceptable to have a standard_name assigned to string
variable. Nothing wrong with a string variable.
-metadata] New standard name: datetime_iso8601 (standard_name
or units?)
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin steven.c.han...@noaa.gov
wrote:
ISO date-time strings are a way of encoding the physical quantity
that we know as TIME. So TIME is the right standard_name for ISO
date-time
@cgd.ucar.edu mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
(standard_name or units?)
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin
steven.c.han...@noaa.gov mailto:steven.c.han...@noaa.gov wrote:
ISO date-time strings are a way of encoding
[cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Chris Barker
- NOAA Federal [chris.bar...@noaa.gov]
Sent: 27 March 2013 15:56
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601 (standard_name
or units?)
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin
15:56
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
(standard_name or units?)
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin steven.c.han...@noaa.gov
wrote:
ISO date-time strings are a way of encoding the physical quantity
that we know
On 3/26/2013 7:20 PM, Aleksandar Jelenak - NOAA Affiliate wrote:
Hi Steve,
On Tue, Mar 19, 2013 at 6:19 PM, Steve Hankin steven.c.han...@noaa.gov wrote:
Hi Aleksander,
A question to debate in your trac ticket. Per the CF documentation, the
definition of the standard_name is /The name used
I am heavily in favor of the units attribute being the way that ISO time
strings are identified.
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin steven.c.han...@noaa.gov wrote:
ISO date-time strings are a way of encoding the physical quantity
that we know as TIME. So TIME is the right standard_name for ISO
date-time strings per the definition quoted above.
Now, it may be that there is
On 3/27/2013 8:56 AM, Chris Barker - NOAA Federal wrote:
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin steven.c.han...@noaa.gov wrote:
ISO date-time strings are a way of encoding the physical quantity
that we know as TIME. So TIME is the right standard_name for ISO
date-time strings per
Dear Aleksandar
Is the proposal for the use of date-time strings in auxiliary coordinate
variables only, not in (Unidata) coordinate variables,
to provide a human-readable equivalent to the encoded time coordinate
variable?
Not exclusively. It could be used for that purpose but I
Dear John
Probably my proposal comes down to 2 parts, which are separable:
1. Find a suitable replacement for udunits as a reference library
for CF calendar dates. Unfortunately, udunits used a slightly
non-standard syntax, which we need to still be legal for backwards
compatibility. So
On Mon, Mar 25, 2013 at 2:33 AM, Jonathan Gregory
2. Allow a suitable string syntax for date/times, probably expressed
as a profile of ISO8601
..snip...
Obviously opinion is divided on this, if it means allowing time-date coord
variables which are string-valued, as an alternative to the
On Thu, Mar 21, 2013 at 1:14 PM, John Caron ca...@unidata.ucar.edu wrote:
On 3/21/2013 11:17 AM, Chris Barker - NOAA Federal wrote:
On Tue, Mar 19, 2013 at 5:21 PM, Dave Allured - NOAA Affiliate
dave.allu...@noaa.gov wrote:
You are making a set of technical
use specifications, with
On Thu, Mar 21, 2013 at 12:14 PM, John Caron ca...@unidata.ucar.edu wrote:
Ive always just worked with the W3C profile of ISO8601
http://www.w3.org/TR/NOTE-datetime
So theres the question of supporting full ISO8601, or just a profile.
That looks like a good profile to me -- and documented,
Hi all,
I'm a bit late to the discussion, but I just want to go on the record as being
(fairly strongly) opposed to allowing *anything* to be expressed as a string
if there's a reasonable numeric representation we can use instead.
Maybe I'll change my mind after the community has made the jump
-metadata] New standard name: datetime_iso8601
Message-ID: web-45204...@mail.ucar.edu
Content-Type: text/plain;charset=utf-8
Hi all,
I'm a bit late to the discussion, but I just want to go on the record as being
(fairly strongly)
opposed to allowing *anything* to be expressed as a string if there's
The standard way CF deals with time is one of its most attractive
features; time is most difficult thing to understand in a 'generic'
NetCDF file.
My concern is that - as John G and at least 1 other person on this
thread have indicated - the addition of ISO string times is just the
beginning of
Dear all,
as I am the at least one other person to whom Nan refered, let me
clarify my position:
1) I would strongly argue against adding another way of formatting time through
the backdoor via a standard_name.
2) I do see quite a bit of sense in re-modeling the date and time handling in
Dear all,
building on what Martin said here I want to clarify my views on this in
less words than last time.
Essentially, I can fully agree with Martin. And the date handling of
CF/NetCDF could probably be improved. However, this should be done in a
way that does not introduce redundancies into
On 3/21/2013 8:25 AM, John Caron wrote:
Probably my proposal comes down to 2 parts, which are separable:
1. Find a suitable replacement for udunits as a reference library for
CF calendar dates. Unfortunately, udunits used a slightly non-standard
syntax, which we need to still be legal for
On 3/21/2013 9:41 AM, Steve Hankin wrote:
On 3/21/2013 8:25 AM, John Caron wrote:
Probably my proposal comes down to 2 parts, which are separable:
1. Find a suitable replacement for udunits as a reference library for
CF calendar dates. Unfortunately, udunits used a slightly
non-standard
Hi John,
I'm probably repeating what others have said, but allowing strings as
actual (rather than ancillary) coordinate values would break lots of
quick look software which can't plot variables which are functions
of a string representation of the independent variable (i.e, time). If
I'm
John,
On 03/21/2013 09:25 AM, John Caron wrote:
1. ... Unfortunately, udunits used a slightly non-standard
syntax ...
More correctly, the UDUNITS packages accept the ISO standard syntax as
well as some non-standard syntaxes.
I believe this is an example of no good deed (being generous in what
On Tue, Mar 19, 2013 at 5:21 PM, Dave Allured - NOAA Affiliate
dave.allu...@noaa.gov wrote:
You are making a set of technical
use specifications, with significant departures from the reference
standard ISO 8601.
If we do anything with this -- PLEASE, PLEASE, PLEASE simply use the
ISO
Dear all,
interesting discussion. From the point of view of an outsider (not dealing
with ocean data ;-) there are two issues which still aren't entirely clear to
me:
1) as Steve Hankin wrote, this variable has a potential to deflect from the
actual physical quantity, which is expressed
Dear all,
after reading through the unusally vivid discussion on this issue, I
feel like I have to make a statement as well. My background being the
experience with not-so-CF-compliant CF-netCDF datasets submitted to us
by several different groups and the resulting development of a CFchecker
to
Hi all:
Another thing to consider is the relationship to the current udunit/CF
standard for specifying dates in the unit string
period SINCE date
The udunits documentation
http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2lib.html#Grammar
not being very clear, I wrote up my
Hi.
I'm opposed to the addition of a standard name. Standard names are
intended to identify classes, or types of things. As I look at it, the
goal is to keep implementation details out of standard names. ISO8601 is
an implementation, so I think it has no place in the standard name
vocabulary.
Hello,
My beer/coffee/perocet levels are too low to want to comment broadly on
this, so I'll just make one comment ...
Really the main advantage is that data writers are less likely to
make a mistake specifying
1952-08-15T00:00:00Z
than
2434567 days since -4713-01-01T00:00:00Z.
I'm
On 3/20/2013 9:41 AM, David Hassell wrote:
Hello,
My beer/coffee/perocet levels are too low to want to comment broadly on
this, so I'll just make one comment ...
Really the main advantage is that data writers are less likely to
make a mistake specifying
1952-08-15T00:00:00Z
than
2434567
On 03/20/2013 04:51 PM, John Caron wrote:
I guess the point is that its not always fair to assume that, and the
user wont know when it fails, esp for
'2434567 days since -4713-01-01T00:00:00Z'
unless she also computes
'1952-08-15T00:00:00Z'
which presumably she could do as a double
Correction, I said this yesterday:
If leap seconds are excluded, then the correct [value of
the CF calendar attribute] should be proleptic_gregorian.
In the most common cases where the data is fully within the range of
the Gregorian calendar, the calendar attribute should be simply
gregorian.
On 3/20/2013 7:58 AM, John Caron wrote:
Hi all:
I guess I started this messy discussion, then invited everyone to
drink too much and say whatever they wanted. The conversation gets a
bit loud and fuzzy. So now we've switched back to caffeine and the
sober realities of deciding on grammars
Hello Steve,
On Tue, Mar 19, 2013 at 6:19 PM, Steve Hankin steven.c.han...@noaa.gov wrote:
A question to debate in your trac ticket. Per the CF documentation, the
definition of the standard_name is The name used to identify the physical
quantity
...@cgd.ucar.edu] *On Behalf
Of *Steve Hankin
*Sent:* 24 February 2013 19:07
*To:* John Caron
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] New standard name: datetime_iso8601
On 2/23/2013 1:41 PM, John Caron wrote:
Hi Chris, and all:
On 1/11/2013 2:37 PM, Chris Barker - NOAA Federal wrote
Dear all
While I agree that 35246 hours since 1970-01-01 is not helpful to humans,
I agree with Steve that we should not allow an alternative representation of
time in CF, and that we should depend on software to do the encoding and
decoding into more easily understable strings (just as we depend
Thanks Aleksander for pushing in this direction.
This proposal is a very helpful way forward, both for capturing data coming
from sensors in an ISO8601 format (a steadily increasing number), and for
letting some of us add information in a human-readable format for direct human
use. Which,
There seems to be surprisingly broad support for this idea, so I've been
re-reading the thread, looking for a reasonable use case. I can't say that
I've found any description of why we actually need this - am I missing
something?
Anyway, going back to Aleksandar's original (slightly amended)
I tried to capture pretty much all the variations for datetime instances.
That is ideal, thanks.
John
On Mar 19, 2013, at 11:51, Aleksandar Jelenak - NOAA Affiliate
aleksandar.jele...@noaa.gov wrote:
On Tue, Mar 19, 2013 at 12:57 PM, John Graybeal jgrayb...@ucsd.edu wrote:
Thanks
Use Cases:
1) I am documenting an ISO-8601-compliant time variable from an instrument or
application, which I would rather capture in its raw string form than convert
to another form.
2) I would like to present some time variable in human-readable form, so that
users of netCDF clients that
Dear Aleksandar
Thanks for clarifying your proposal. I am one of those who misinterpreted you,
then. Sorry about that. Is the proposal for the use of date-time strings in
auxiliary coordinate variables only, not in (Unidata) coordinate variables,
to provide a human-readable equivalent to the
Aleksandar,
I support the standard name proposal for datetime_iso8601. However, I
see several areas needing refinement, evidenced by today's messages.
Would you like to start a trac ticket for further discussion? If you
prefer, I can post my particular concerns on the CF main list.
--Dave
On
Nan,
On Tue, Mar 19, 2013 at 3:08 PM, Nan Galbraith ngalbra...@whoi.edu wrote:
There seems to be surprisingly broad support for this idea, so I've been
re-reading the thread, looking for a reasonable use case. I can't say that
I've found any description of why we actually need this - am I
Dave,
Please post here. I don't want to lose this momentum now... :-)
-Aleksandar
On Tue, Mar 19, 2013 at 3:55 PM, Dave Allured - NOAA Affiliate
dave.allu...@noaa.gov wrote:
Aleksandar,
I support the standard name proposal for datetime_iso8601. However, I
see several areas needing
February 2013 19:07
*To:* John Caron
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] New standard name: datetime_iso8601
On 2/23/2013 1:41 PM, John Caron wrote:
Hi Chris, and all:
On 1/11/2013 2:37 PM, Chris Barker - NOAA Federal wrote:
On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar
To: John Caron
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
On 2/23/2013 1:41 PM, John Caron wrote:
Hi Chris, and all:
On 1/11/2013 2:37 PM, Chris Barker - NOAA Federal wrote:
On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
://www.metoffice.gov.uk/
*From:* CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On Behalf
Of *Steve Hankin
*Sent:* 24 February 2013 19:07
*To:* John Caron
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] New standard name
I'm still a bit confused about whether this is proposed as an
alternative to or an addtion to, the existing time-since-date approach
-- i.e would creators of CF files need to choose which to use? or
could use both in one file? or does someone want to deprecate the old
way?
Anyway, a comment or
-Original Message-
From: CF-metadata on behalf of Russ Rew
Sent: Mon 14/01/2013 15:56
To: ngalbra...@whoi.edu
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
=20
Nan and Chris,
I agree with Chris.
=20
Having ncdump or other clients show
Hello Aleksandar,
I've seen some files which did such duplication, even if they haven't
been CF-compliant. If it doesn't need to be machine-readable, you can
put that information where-ever you want and you don't need a
standard_name for that.
But I can only give a warning for duplication:
on other days is possible but not guaranteed!
-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Heiko
Klein
Sent: 15 January 2013 09:09
To: Aleksandar Jelenak - NOAA Affiliate
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name
I agree with Chris.
Having ncdump or other clients show dates in an ISO-compliant format
is a fine idea, as is using ISO strings for dates in attributes, but those
are completely different from storing date variables as strings.
NetCDF uses a binary storage format and is not meant to be human
Nan and Chris,
I agree with Chris.
Having ncdump or other clients show dates in an ISO-compliant format
is a fine idea, as is using ISO strings for dates in attributes, but those
are completely different from storing date variables as strings.
Yes, since version 4.2, ncdump has supported
On Mon, Jan 14, 2013 at 7:56 AM, Russ Rew r...@unidata.ucar.edu wrote:
Yes, since version 4.2, ncdump has supported the -t and -T options
for showing dates and times in human-readable and ISO-compliant format,
Wow! I'd never noticed that -- very handy, thanks!
I actually used ncdump as a
Hello Nan, Chris:
I am not proposing that time coordinate variables can also be ISO 8601
datetime strings. The description for this standard name clearly
states:
Variables with this standard name cannot serve as coordinate variables.
I am merely proposing a standard name for those who are
Dear all,
Shouldn't one allow room for storing leap seconds? (ss in range 00-60 instead
of 00-59)
Best regards,
Sander
On 11 jan. 2013, at 18:00, Aleksandar Jelenak - NOAA Affiliate
aleksandar.jele...@noaa.gov wrote:
Dear All:
Here's the modified proposal for the datetime_iso8601
Dear Sander,
On Fri, Jan 11, 2013 at 12:22 PM, Sander Niemeijer niemei...@stcorp.nl wrote:
Shouldn't one allow room for storing leap seconds? (ss in range 00-60 instead
of 00-59)
Yes, you are correct. The corrected statement is:
* ss is a two-digit second (00-60).
-Aleksandar
On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
aleksandar.jele...@noaa.gov wrote:
Here's the modified proposal for the datetime_iso8601 standard name:
...
String representing date-time information according to the ISO
8601:2004(E) standard.
I think we should NOT adopt a
65 matches
Mail list logo
