On 3/22/2011 12:56 PM, Steve Hankin wrote:
On 3/22/2011 5:40 AM, John Caron wrote:
On 3/21/2011 11:55 AM, Karl Taylor wrote:
Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way of
On 3/21/2011 11:14 AM, Steve Hankin wrote:
On 3/17/2011 5:20 PM, John Caron wrote:
On 3/17/2011 12:19 PM, Steve Hankin wrote:
On 3/17/2011 9:50 AM, Christopher Barker wrote:
On 3/16/11 8:47 AM, John Caron wrote:
1. time instants vs time duration
- one must distinguish between
On 3/21/2011 11:55 AM, Karl Taylor wrote:
Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way of encoding time is incomplete. As far as I know the
encoding is indeed complete and given
On 3/22/2011 6:40 AM, John Caron wrote:
Anyway, I think the reliance that CF has on udunits is, um, suboptimal.
but only for calendar time units - for dimensional units its the right stuff
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
Time is an issue, but temperature is not a dimensional unit either --
there is differential temperature (degree_Celsius/degree_Kevin, appropriate
for anomalies), and temperature scale, i.e. Celsius_scale and Kelvin_scale
differ only in the offset. Yes, the offset part does not work as well as
for this use case).
Cheers,
Jon
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Hankin
Sent: 21 March 2011 17:14
To: John Caron
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/17/2011 5:20 PM
Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way of encoding time is incomplete. As far as I know the
encoding is indeed complete and given correct specification of the units
(which
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 point on
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
oceanographic
: [CF-metadata] udunits handling of fuzzy time units
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
Message-
From: cf-metadata-boun...@cgd.ucar.edu [mailto:
cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Emmerson
Sent: 18 March 2011 17:14
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
Martin,
On 03/18/2011 04:11 AM, Schultz, Martin
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
] On Behalf Of Steve Emmerson
Sent: 18 March 2011 17:14
To: cf-metadata@cgd.ucar.edu mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
Martin,
On 03/18/2011 04:11 AM, Schultz, Martin wrote:
PS: I do disagree with Christopher when he
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
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 as
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
On 3/16/11 8:47 AM, John Caron wrote:
1. time instants vs time duration
- one must distinguish between dimensional time (time duration,
units=secs), and calendar time (time instant, or point on the time
continuum) which is not dimensional.
yup -- key clarification in all this.
- calendar
Hi all,
There have been multiple interesting sub-threads of this conversation, and I'm
getting them a bit tangled, not helped by my email client apparently not
distinguishing clearly between quotes and new material.
John C. - are you in a position to make a summary and/or concrete proposal to
Is the whole problem just that when udunits calculates
ISO string dates, it doesn't use the resolution implicit
in the reference date and units? That seems like an easy
problem to solve, without throwing out udunits.
1 months since 1930-01-01 == 1930-02-01
The argument that months years are
-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
Is the whole problem just that when udunits calculates ISO string dates,
it doesn't use the resolution implicit in the reference date and units?
That seems like an easy problem to solve, without throwing out udunits
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk wrote:
Dear All,
At the nit-picking level, day (and hour and minute) are not
necessarily stable units either, because of the occasional appearance
of leap seconds. While this won't be of much concern for many users,
it can be important for
] udunits handling of fuzzy time units
Is the whole problem just that when udunits calculates ISO string dates,
it doesn't use the resolution implicit in the reference date and units?
That seems like an easy problem to solve, without throwing out udunits.
1 months since 1930-01-01 == 1930-02-01
While wikipedia does use the word accuracy, it is clear in the context
that it does not really mean it, and that resolution is more appropriate.
Benno
On Wed, Mar 16, 2011 at 11:52 AM, Nan Galbraith ngalbra...@whoi.edu wrote:
On 3/16/11 10:21 AM, Hedley, Mark wrote:
I think one the
On 3/16/2011 9:39 AM, John Caron wrote:
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk wrote:
Dear All,
At the nit-picking level, day (and hour and minute) are not
necessarily stable units either, because of the occasional appearance
of leap seconds. While this won't be of much concern
there, but they are related.
Jon
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 16 March 2011 17:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/16/2011 9:39 AM, John
Hi Jonathan:
On 3/16/2011 10:46 AM, Jonathan Gregory wrote:
Dear John
Thanks for your useful summary.
thanks!
- udunits should no longer be the reference library for calendar
time. a new reference library is needed, which handles non-standard
calendars.
If udunits itself were extended
Dear John
Suppose we added the UTC_Calendar to CF, which tracks leap seconds
etc. So if one had the time coordinate days since 1800-01-01 with
values = 0,1,2,3... and we need the resulting coordinates to be
1800-01-01, 1800-01-02, 1800-01-03, 1800-01-04, which in
this calendar gives an
Jonathan,
On 03/16/2011 10:46 AM, Jonathan Gregory wrote:
If udunits itself were extended to cover non-real-world calendars, wouldn't
that be OK?
That idea is easy to say (or request) but it would be very difficult to
implement because one of the most fundamental assumptions of the UDUNITS
Dear Steve
If udunits itself were extended to cover non-real-world calendars, wouldn't
that be OK?
That idea is easy to say (or request) but it would be very difficult to
implement because one of the most fundamental assumptions of the UDUNITS
library -- one around which the library is
-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 16 March 2011 17:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/16/2011 9:39 AM, John Caron wrote:
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk
On 3/16/2011 11:15 AM, Jonathan Gregory wrote:
Dear John
Suppose we added the UTC_Calendar to CF, which tracks leap seconds
etc. So if one had the time coordinate days since 1800-01-01 with
values = 0,1,2,3... and we need the resulting coordinates to be
1800-01-01, 1800-01-02, 1800-01-03,
On 3/16/2011 8:47 AM, John Caron wrote:
On 3/16/2011 3:57 AM, Jon Blower wrote:
Hi all,
There have been multiple interesting sub-threads of this
conversation, and I'm getting them a bit tangled, not helped by my
email client apparently not distinguishing clearly between quotes and
new
On Wed, Mar 16, 2011 at 5:06 PM, Steve Hankin steven.c.han...@noaa.govwrote:
P.S. Together with enhancing udunits to handle the formatting of
date-time strings,it would be natural to add the same functionality for
longitudes, too. Ditto degrees of temperature -- degrees F, C and K.
...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 15 March 2011 00:31
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] udunits handling of fuzzy time units
because udunits converts units like months and years to a fixed number
of seconds, one cant really use things
: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 15 March 2011 00:31
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] udunits handling of fuzzy time units
because udunits converts units like months and years to a fixed number
: [CF-metadata] udunits handling of fuzzy time units
because udunits converts units like months and years to a fixed number
of seconds, one cant really use things like months and years as units,
since you get things like this:
0 months since 1930-01-01 == 1930-01-01T00:00:00Z
1 months
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
is not a proper unit and not only depends on month of year, but also
on assumed calendar (and similarly for year). Therefore, I think
months since and years since
Of John Caron
Sent: 15 March 2011 13:02
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
is not a proper unit and not only
John et. al.,
It looks like this thread has reached reasonable conclusions:
1. units of days (or secs or mins) can provide an accurate encoding
for months (days since 1930-01-01)
2. units of measure should not be quantities that vary
3. udunits could in principle offer calendar
] On Behalf Of John Caron
Sent: 15 March 2011 13:02
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
is not a proper unit
mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence
month
is not a proper unit and not only depends
Hi Steve:
On 3/15/2011 10:13 AM, Steve Hankin wrote:
John et. al.,
It looks like this thread has reached reasonable conclusions:
1. units of days (or secs or mins) can provide an accurate encoding
for months (days since 1930-01-01)
2. units of measure should not be quantities that
[mailto:bennoblument...@gmail.com] On Behalf Of
Benno Blumenthal
Sent: 15 March 2011 15:20
To: Jon Blower
Cc: John Caron; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
I am sorry, but this conversation is more confusing that it needs to be -- once
calendar
On 3/15/2011 9:28 AM, John Caron wrote:
On 3/15/2011 9:19 AM, Benno Blumenthal wrote:
I am sorry, but this conversation is more confusing that it needs to
be -- once calendar 360_day is chosen, there is nothing fuzzy about
month or year, and once calendar 365_day or 366_day is chosen, there
*To:* Jon Blower
*Cc:* John Caron; cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] udunits handling of fuzzy time units
I am sorry, but this conversation is more confusing that it needs to be --
once calendar 360_day is chosen, there is nothing fuzzy about month or
year, and once calendar
On 3/15/2011 12:07 PM, Steve Hankin wrote:
On 3/15/2011 9:28 AM, John Caron wrote:
On 3/15/2011 9:19 AM, Benno Blumenthal wrote:
I am sorry, but this conversation is more confusing that it needs to
be -- once calendar 360_day is chosen, there is nothing fuzzy
about month or year, and once
...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 15 March 2011 13:02
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
On 3/15/11 12:18 PM, John Caron wrote:
I'd propose that a good way of thinking about the distinction between
dates and times is that time is a geospatial unit of measure ,
whereas date (which includes time of day) is a way of formatting
time units for human readability.
Hmm. the time libs I've
On 3/15/11 12:30 PM, tim.nighting...@stfc.ac.uk wrote:
At the nit-picking level, day (and hour and minute) are not
necessarily stable units either, because of the occasional appearance
of leap seconds. While this won't be of much concern for many users,
it can be important for precisely
Chris,
On 03/15/2011 03:59 PM, Christopher Barker wrote:
So what are reasonable units to express timedeltas in?
I think the point here is that months or years is simply not
appropriate for that, period.
It can be usefull to express monthly averages, and the like -- it does
help with our
because udunits converts units like months and years to a fixed number
of seconds, one cant really use things like months and years as units,
since you get things like this:
0 months since 1930-01-01 == 1930-01-01T00:00:00Z
1 months since 1930-01-01 == 1930-01-31T10:29:03Z
2 months since
There are several existing solutions to your question, depending on
the constraints or requirements of your application. Some of these
use encodings that are not supported by Udunits, but are explicitly
legal under the current version of CF. Here are two leading solutions:
1. time@units =
53 matches
Mail list logo
