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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>] *On Behalf Of *Jim Biard
>>>>>>>> *Sent:* 15 March 2017 16:28
>>>>>>>> *To:* [email protected]
<mailto:[email protected]>
>>>>>>>> *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 <[email protected]
<mailto:[email protected]>>
>>>>>>>> <mailto:[email protected]
<mailto:[email protected]>> on behalf of Jim
>>>>>>>> Biard <[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>>
>>>>>>>> *Date: *Tuesday, 14 March 2017 15:12
>>>>>>>> *To: *"[email protected]
<mailto:[email protected]>"
>>>>>>>> <mailto:[email protected]
<mailto:[email protected]>> <[email protected]
<mailto:[email protected]>>
>>>>>>>> <mailto:[email protected]
<mailto:[email protected]>>
>>>>>>>> *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
>>>
>>> [email protected] <mailto:[email protected]>
>>> 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: [email protected] <mailto:[email protected]>
>> o: +1 828 271 4900
>>
>> Connect with us on Facebook for climate and ocean and
geophysics information, and follow us on Twitter at
@NOAANCEIclimate and @NOAANCEIocngeo.
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>>
>> [email protected] <mailto:[email protected]>
>> 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
> [email protected] <mailto:[email protected]>
> 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: [email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
