We use the term yearday; even this is imprecise, because it can be
calculated
at least 2 different ways.
We always include a reference to (and definition of) the Naval yearday
convention,
which defines noon on January 1 as yearday 1.5, not 0.5.
For time series data that we publish (to OceanSITES, mainly) we use the
'normal'
CF "days since 1950-01-01 00:00:00", but for climatology data and other
internal
data, we use whatever is convenient.
Cheers - Nan
On 3/16/17 4:48 PM, Dave Allured - NOAA Affiliate wrote:
> Here is a credible appeal to avoid the terms Julian Date and Julian
> Day in any scientific usage, to mean Day of Year. Citing document
> MODIFIED JULIAN DATE, M. R. Winkler, formerly with U.S. Naval Observatory:
>
> http://tycho.usno.navy.mil/mjd.html
>
> """ The MJD (and even more so the JD) has to be well distinguished
> from this day of the year (DOY). This is also often but erroneously
> called Julian Date, when in fact it is a Gregorian Date expressed as
> number of days in the year. This is a grossly misleading practice that
> was introduced by some who were simply ignorant and too careless to
> learn the proper terminology. It creates a confusion which should not
> be taken lightly. Moreover, a continuation of the use of expressions
> "Julian" or "J" day in the sense of a Gregorian Date will make matters
> even worse. It will inevitably lead to dangerous mistakes, increased
> confusion, and it will eventually destroy whatever standard practices
> exist. """
>
> Though I also have used these terms in the past, I now agree with this
> opinion. I would suggest that CF Conventions should use only Day of
> Year (DOY) or some similar term for this purpose.
>
> --Dave
>
>
> On Thu, Mar 16, 2017 at 1:56 PM, Roy Mendelssohn - NOAA Federal
> <roy.mendelssohn at noaa.gov <mailto:roy.mendelssohn at noaa.gov>> wrote:
>
> Julian day is used in several different ways, as John says:
>
> https://landweb.modaps.eosdis.nasa.gov/browse/calendar.html
> <https://landweb.modaps.eosdis.nasa.gov/browse/calendar.html>
>
> -Roy
>
> > On Mar 16, 2017, at 12:49 PM, John Helly <hellyj at ucsd.edu
> <mailto:hellyj at ucsd.edu>> wrote:
> >
> > In language, definitions are based on usage. Julian date, modulo
> the year, is a convention that I have been using for decades to do
> what you are talking about but I defer to wiser minds.
> >
> > J.
> >
> > On 3/16/17 9:42 AM, Jim Biard wrote:
> >> John,
> >>
> >> As best as I understand it, Julian day is a term that is
> grossly misused. Julian Day is defined as the elapsed days since
> January 1, 4713 BCE. Lots of people use the term to refer to
> day-in-year, but this doesn't seem to be a proper usage.
> >>
> >> Grace and peace,
> >>
> >> Jim
> >>
> >> On 3/16/17 3:36 PM, John Helly wrote:
> >>> Sorry to jump in here but isn't this just the Julian day?
> >>>
> >>> J.
> >>>
> >>>
> >>> On 3/16/17 8:24 AM, Nan Galbraith wrote:
> >>>> I agree that there's a lot of interest, and I have 2 questions.
> >>>>
> >>>> To make the data most useful, shouldn't the time coordinate
> variable be
> >>>> Jan 1, and shouldn't the 'days since' (data) variable
> represent the yearday
> >>>> within that year?
> >>>>
> >>>> My specific concerns with Jim's approach:
> >>>>
> >>>> first_freeze_date:units = "days since 1900-01-01 00:00:00"
> - This doesn't seem
> >>>> to me to provide the most easily used data point, wouldn't
> the year-day be more
> >>>> convenient, for seeing how this value varies over the years?
> >>>>
> >>>> And with Antoio's:
> >>>>
> >>>> first_freeze_date:coordinates="threshold time"; - I don't see
> how threshold,
> >>>> which is a temperature, can be a coordinate of this variable.
> Also, I'd like to know
> >>>> why setting time:units="days since 2000-6-1"; is preferable
> to using 2000-1-1;
> >>>> doesn't this invite errors in using the time in applications
> like matlab and python?
> >>>>
> >>>> Actually, the metadata doesn't tell me how to interpret the
> values in first_freeze_date -
> >>>> the short name implies that they're dates, the units implies
> they're elapsed days, but
> >>>> without a reference date to enable decoding.
> >>>>
> >>>> Cheers - Nan
> >>>>
> >>>>
> >>>> On 3/16/17 8:45 AM, Jim Biard wrote:
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>> There is clearly interest here! I agree that day_in_year is
> rather generic, and there should probably be a more precise term.
> I'm not so sure about the cell_methods that were suggested below.
> In my particular case the values are derived from a daily Tmin
> product. Each value is the date of the first Tmin < 0 C within the
> time bounds. If it was a spell length, such as growing season
> length, then I can see the need for a more climatological cell_method.
> >>>>>
> >>>>> We can keep this up and work up some standard_name
> definitions to propose. I'm sure the results will be better if we
> collaborate compared to what I'd do on my own.
> >>>>>
> >>>>> Grace and peace,
> >>>>>
> >>>>> Jim
> >>>>>
> >>>>>
> >>>>> On 3/16/17 7:23 AM, Antonio S. Cofi?o wrote:
> >>>>>> Dear all,
> >>>>>> There is no standard_name for the concept but there are 2
> different ones which delimit the approach that it could be used as
> templates for the new one:
> >>>>>> *time_when_flood_water_falls_below_threshold
> *(time_when_flood_water_rises_above_threshold and
> time_of_maximum_flood_depth are also good examples )
> >>>>>>
> http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#time_when_flood_water_falls_below_threshold_tr
> <http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#time_when_flood_water_falls_below_threshold_tr>
> >>>>>>> The quantity with standard name
> *time_when_flood_water_falls_below_threshold*: is the time elapsed
> between the breaking of a levee (origin of flood water simulation)
> and the instant when the depth falls below a given threshold for
> the last time, having already risen to its maximum depth, at a
> given point in space. If a threshold is supplied, it should be
> specified by associating a coordinate variable or scalar
> coordinate variable with the data variable and giving the
> coordinate variable a standard name of flood_water_thickness. The
> values of the coordinate variable are the threshold values for the
> corresponding subarrays of the data variable. If no threshold is
> specified, its value is taken to be zero. Flood water is water
> that covers land which is normally not covered by water.
> >>>>>> the problem is the event definition, which is quite
> different to the one it's been considered here which is more like
> a climatological statistics. The good thing is the CF already has
> some good definitions for those climatological statistics, like
> Example 7.11 on CF1.6 document:
> >>>>>>
> http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#extreme-statistics-and-spell-lengths-ex
> <http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#extreme-statistics-and-spell-lengths-ex>
> >>>>>>
> >>>>>> And more convenient definition of this climatological
> statistics could be:
> >>>>>>
> http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#spell_length_of_days_with_air_temperature_above_threshold_tr
> <http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#spell_length_of_days_with_air_temperature_above_threshold_tr>
> >>>>>>> Air temperature is the bulk temperature of the air, not
> the surface (skin) temperature. A spell is the number of
> consecutive days on which the condition X_below|above_threshold is
> satisified. A variable whose standard name has the form
> spell_length_of_days_with_X_below|above_threshold *must have a
> coordinate variable or scalar coordinate variable with the a
> standard name of X to supply the threshold*(s).*It must have a
> climatological time variable, and a cell_method entry* for within
> days which describes the processing of quantity X before the
> threshold is applied. A spell_length_of_days is an intensive
> quantity in time, and the cell_methods entry for over days can be
> any of the methods listed in Appendix E appropriate for intensive
> quantities e.g. "maximum", "minimum" or "mean".
> >>>>>>
> >>>>>> And this definition gives a more appropriate way to encode
> the date of freezing days using a auxiliary coordinate to specify
> the threshold and use a cell_methods attribute along with the
> climatology_bounds attribute on time coordinate to specify an
> statistics over a period.
> >>>>>>
> >>>>>> The standard_name should be more like the definition for
> spell_length_of_days, but removing using 'time' as general instead
> of days. This what I would suggest with respect to the encoding:
> >>>>>>
> >>>>>> variables:
> >>>>>> float first_freeze_date(lat,lon);
> >>>>>>
> first_freeze_date:standard_name="time_when_air_temperature_below_threshold";
> >>>>>> first_freeze_date:coordinates="threshold time";
> >>>>>> first_freeze_date:cell_methods="time: minimum within
> days time: minimum over days";
> >>>>>> first_freeze_date:units="days";
> >>>>>> float last_freeze_date(lat,lon);
> >>>>>>
> last_freeze_date:standard_name="time_when_air_temperature_below_threshold";
> >>>>>> last_freeze_date:coordinates="threshold time";
> >>>>>> last_freeze_date:cell_methods="time: minimum within days
> time: maximum over days";
> >>>>>> last_freeze_date:units="days";
> >>>>>> float threshold;
> >>>>>> threshold:standard_name="air_temperature";
> >>>>>> threshold:units="degC";
> >>>>>> double time;
> >>>>>> time:climatology="climatology_bounds";
> >>>>>> time:units="days since 2000-6-1";
> >>>>>> double climatology_bounds(time,nv);
> >>>>>> data: // time coordinates translated to date/time string
> type format
> >>>>>> time="2008-01-16T00:00";
> >>>>>> climatology_bounds="2007-08-01T00:00", "2008-05-31T00:00";
> >>>>>> threshold=0.;
> >>>>>>
> >>>>>> The time: minimum over days, on first_freeze_date
> cell_methods attribute represents the shortest time minimum daily
> temperature (time: minimum within days) is below threshold.
> >>>>>> Equivalent for the last_freeze_date, but in this cas
> represents the longest time (time: maximum over days).
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> Antonio
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Antonio S. Cofi?o
> >>>>>> Associate Professor and Researcher
> >>>>>> Grupo de Meteorolog?a de Santander
> >>>>>> Dep. of Applied Mathematics and Computer Sciences
> >>>>>> Universidad de Cantabria (Spain)
> >>>>>>
> >>>>>> Academic Visitor
> >>>>>> National Centre for Atmospheric Science
> >>>>>> Department of Meteorology
> >>>>>> School of Mathematical, Physical and Computational Sciences
> >>>>>> University of Reading (UK)
> >>>>>>
> >>>>>> http://antonio.cofino.es
> >>>>>> On 15/03/17 18:16, Jim Biard wrote:
> >>>>>>>
> >>>>>>> Dan,
> >>>>>>>
> >>>>>>> How about that? I'm working on similar products. We
> haven't even considered standard names for them.
> >>>>>>>
> >>>>>>> I went ahead and used 'days since YYYY-MM-DD 00:00:00' for
> my first and last frost dates, since they are valid dates. My
> files are structured as (example for first frost date):
> >>>>>>>
> >>>>>>> dimensions:
> >>>>>>> time = UNLIMITED ; // (56 currently)
> >>>>>>> lon = 960 ;
> >>>>>>> lat = 490 ;
> >>>>>>> bnds = 2 ;
> >>>>>>> variables:
> >>>>>>> double time(time) ;
> >>>>>>> time:standard_name = "time" ;
> >>>>>>> time:long_name = "time" ;
> >>>>>>> time:axis = "T" ;
> >>>>>>> time:units = "days since 1900-01-01 00:00:00" ;
> >>>>>>> time:calendar = "gregorian" ;
> >>>>>>> time:bounds = "time_bounds" ;
> >>>>>>> double time_bounds(time, bnds) ;
> >>>>>>> double lon(lon) ;
> >>>>>>> lon:standard_name = "longitude" ;
> >>>>>>> lon:long_name = "longitude" ;
> >>>>>>> lon:units = "degrees_east" ;
> >>>>>>> lon:modulo = 360. ;
> >>>>>>> lon:axis = "X" ;
> >>>>>>> lon:bounds = "lon_bounds" ;
> >>>>>>> double lon_bounds(lon, bnds) ;
> >>>>>>> double lat(lat) ;
> >>>>>>> lat:standard_name = "latitude" ;
> >>>>>>> lat:long_name = "latitude" ;
> >>>>>>> lat:units = "degrees_north" ;
> >>>>>>> lat:axis = "Y" ;
> >>>>>>> lat:bounds = "lat_bounds" ;
> >>>>>>> double lat_bounds(lat, bnds) ;
> >>>>>>> float first_freeze_date(time, lat, lon) ;
> >>>>>>> first_freeze_date:_FillValue = 1.e+20f ;
> >>>>>>> first_freeze_date:missing_value = 1.e+20f ;
> >>>>>>> first_freeze_date:comment = "Date of the first
> >>>>>>> day with a minimum temperature at or below 0 degrees C
> over the
> >>>>>>> 9 month period starting Aug 1 of each year." ;
> >>>>>>> first_freeze_date:flag_meanings =
> >>>>>>> "No_Freeze_Following" ;
> >>>>>>> first_freeze_date:long_name = "First freeze date" ;
> >>>>>>> first_freeze_date:valid_min = 0. ;
> >>>>>>> first_freeze_date:flag_values = -2. ;
> >>>>>>> first_freeze_date:units = "days since 1900-01-01
> >>>>>>> 00:00:00" ;
> >>>>>>> first_freeze_date:calendar = "standard" ;
> >>>>>>>
> >>>>>>> with the time bounds reflecting 1 Aug to 1 May for each year.
> >>>>>>>
> >>>>>>> On 3/15/17 1:50 PM, Hollis, Dan wrote:
> >>>>>>>>
> >>>>>>>> Hi Jon,
> >>>>>>>>
> >>>>>>>> I?d be interested to know how to tackle this problem too.
> I?ve recently been generating some datasets of ?date of first
> frost? and ?date of last frost? and have no idea how to describe
> them in a CF-compliant way.
> >>>>>>>>
> >>>>>>>> Jim?s suggestion of ?day_of_year? is better than just
> ?days?, however this doesn?t capture what the ?something? is that
> has happened, nor that is the first/last/Nth occurrence of that
> event. What sort of events are you looking at?
> >>>>>>>>
> >>>>>>>> In my application I?m just looking at UK data, hence my
> ?year? runs from 1^st July to 30^th June (to span the N Hemisphere
> winter). It?s easy enough to use the bounds to indicate this, but
> I?m then not sure what values to store in the data array. Number
> of days since 1^st July maybe? Or ordinal date (1^st Jan = 1,
> 31^st Dec = 365)?
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>>>
> >>>>>>>> PS I have a whole bunch of other metrics that I?m looking
> at e.g. length of the longest spell, number of spells greater then
> N days etc. These seem even more complicated to describe using CF.
> Something for another post I think...
> >>>>>>>>
> >>>>>>>> *From:*CF-metadata
> [mailto:cf-metadata-bounces at cgd.ucar.edu
> <mailto:cf-metadata-bounces at cgd.ucar.edu>] *On Behalf Of *Jim Biard
> >>>>>>>> *Sent:* 15 March 2017 16:28
> >>>>>>>> *To:* cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>
> >>>>>>>> *Subject:* Re: [CF-metadata] Recording "day of year on
> which something happens"
> >>>>>>>>
> >>>>>>>> Jon,
> >>>>>>>>
> >>>>>>>> I agree that a cell_methods attribute doesn't seem to be
> necessary. A new standard_name like 'day_in_year' or 'day_of_year'
> would likely make things clearer.
> >>>>>>>>
> >>>>>>>> Jim
> >>>>>>>>
> >>>>>>>> On 3/15/17 11:22 AM, Jon Blower wrote:
> >>>>>>>>
> >>>>>>>> Thanks Jim, that?s very helpful. Is cell_methods
> necessary in
> >>>>>>>> this case (for the time axis bounds) ? probably not
> since this
> >>>>>>>> isn?t a statistical quantity like an average, but a value
> >>>>>>>> that?s ?representative? of the year.
> >>>>>>>>
> >>>>>>>> I seem to remember from a while back that there was a
> proposal
> >>>>>>>> to allow time axes to use ?calendar years since X?
> (as opposed
> >>>>>>>> to ?years since X?, which uses a fixed-length UDUNITS
> year),
> >>>>>>>> which might handle this use case. I have been out of
> the loop
> >>>>>>>> for a while, but I can?t find mention of that in the
> CF spec,
> >>>>>>>> so maybe that didn?t go through.
> >>>>>>>>
> >>>>>>>> I might consider requesting a new standard name ?
> ?days? is
> >>>>>>>> good, but I wonder if a more specific one would be
> helpful.
> >>>>>>>>
> >>>>>>>> Best wishes,
> >>>>>>>> Jon
> >>>>>>>>
> >>>>>>>> *From: *CF-metadata <cf-metadata-bounces at cgd.ucar.edu
> <mailto:cf-metadata-bounces at cgd.ucar.edu>>
> >>>>>>>> <mailto:cf-metadata-bounces at cgd.ucar.edu
> <mailto:cf-metadata-bounces at cgd.ucar.edu>> on behalf of Jim
> >>>>>>>> Biard <jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
> <mailto:jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
> >>>>>>>> *Date: *Tuesday, 14 March 2017 15:12
> >>>>>>>> *To: *"cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>"
> >>>>>>>> <mailto:cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>> <cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>>
> >>>>>>>> <mailto:cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>>
> >>>>>>>> *Subject: *Re: [CF-metadata] Recording "day of year
> on which
> >>>>>>>> something happens"
> >>>>>>>>
> >>>>>>>> Jon,
> >>>>>>>>
> >>>>>>>> 1) I'd use 'days'. It is a valid standard name apart
> from the
> >>>>>>>> 'days since date' formalism. It's not perfect, but
> it's legal.
> >>>>>>>> You could, alternatively, request a new standard name.
> >>>>>>>>
> >>>>>>>> 2) Use a time_bounds variable. I would tend to set
> the time to
> >>>>>>>> be July 1 at midnight for each year, and set the
> bounds for
> >>>>>>>> each year to Jan 1 of that year and Jan 1 of the next
> year.
> >>>>>>>>
> >>>>>>>> Grace and peace,
> >>>>>>>>
> >>>>>>>> Jim
> >>>>>>>>
> >>>>>>>> On 3/14/17 10:43 AM, Jon Blower wrote:
> >>>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> We need to structure a NetCDF file that will hold
> a variable that represents the day of the year on which an event
> happened (integers from 0 to 366). This value is recorded every
> year for a number of years. I have a couple of questions about how
> best to do this:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 1. What is the best standard name to use for the
> day of the year? I didn?t find anything in the standard name
> table, although I might have missed it.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2. What would be the best way to define the time
> axis? Each point along the axis would represent a whole year,
> rather than an instant in time. I could simply pick an arbitrary
> instant (e.g. midnight on 1st Jan) to represent the year, but is
> there a better way?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks in advance for any help!
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Jon
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>>
> >>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> >>
> >> --
> >> <Mail Attachment.png> Visit us on
> >> Facebook Jim Biard
> >> Research Scholar
> >> Cooperative Institute for Climate and Satellites NC
> >> North Carolina State University
> >> NOAA National Centers for Environmental Information
> >> formerly NOAA?s National Climatic Data Center
> >> 151 Patton Ave, Asheville, NC 28801
> >> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> >> o: +1 828 271 4900
> >>
> >> Connect with us on Facebook for climate and ocean and
> geophysics information, and follow us on Twitter at
> _at_NOAANCEIclimate and @NOAANCEIocngeo.
> >>
> >>
> >> _______________________________________________
> >> CF-metadata mailing list
> >>
> >> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
> >
> > --
> > John Helly, University of California, San Diego / San Diego
> Supercomputer Center / Scripps Institution of Oceanography / 760
> 840 8660 mobile /
> > http://www.sdsc.edu/~hellyj <http://www.sdsc.edu/%7Ehellyj>
> >
> > ORCID ID: orcid.org/0000-0002-3779-0603
> <http://orcid.org/0000-0002-3779-0603>
> >
> > <hellyj.vcf>_______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>
> **********************
> "The contents of this message do not reflect any position of the
> U.S. Government or NOAA."
> **********************
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: Roy.Mendelssohn at noaa.gov <mailto:Roy.Mendelssohn at noaa.gov>
> www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward
> justice" -MLK Jr.
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
Received on Fri Mar 17 2017 - 07:05:56 GMT
