[ncl-talk] incorrect date using cd_calendar (and cd_string)?

[Dennis Shea]

DaveA, you should have been a lawyer!!!  :-)

That is a bug. I have filed a JIRA ticket (NCL-2690) for 6.5.0.

I agree with Denise. Forcing the value associated with the calendar
attribute to lower case is a solution.

D

On Thu, Nov 16, 2017 at 5:30 AM, Denise Worthen - NOAA Affiliate <
denise.worthen at noaa.gov> wrote:

> Thanks everyone for your help.  I agree Julian is an odd choice, but it
> wasn't mine (the file originates from MOM6 output). It did dawn on me about
> 30 minutes after hitting send that the problem was the case (JULIAN vs
> julian). Duh.
>
> I've been able to correct the issue by using timeCalendar =
> f->time at calendar followed by timeval at calendar=str_lower(timeCalendar).
>
> This seems like a good thing to do by default since cd_calendar and
> cd_string expect lower case.
>
> Denise.
>
>
>
> On Wed, Nov 15, 2017 at 8:57 PM, Dave Allured - NOAA Affiliate <
> dave.allured at noaa.gov> wrote:
>
>> Dennis,
>>
>> Ah, thanks for finding the actual problem.  However, in CF section 2.6,
>> "Attributes", VALUES of character attributes have a different rule than
>> attribute NAMES:
>>
>>     "... When this standard defines string attributes that may take
>>     various prescribed values, the possible values are generally
>>     given in lower case. However, applications programs should
>>     not be sensitive to case in these attributes ..."
>>
>> So "JULIAN" and "julian" should both be correct, and the file is CF
>> compliant.  Regardless, the best interim fix for Denise is to convert the
>> calendar attribute to lowercase, before using date functions like
>> cd_calendar.
>>
>> I agree that attribute NAMES such as "units" and "calendar" must be lower
>> case according to CF.
>>
>> --Dave
>>
>>
>> On Wed, Nov 15, 2017 at 5:59 PM, Dennis Shea <shea at ucar.edu> wrote:
>>
>>> Ummm,  I don't this is a bug.
>>>
>>> I think the file does not adhere to the Climate and Forecast netCDF
>>> convention
>>>
>>> [1] CF Convention: calendar attribute
>>>
>>>      http://cfconventions.org/Data/cf-conventions/cf-conventions-
>>> 1.6/build/cf-conventions.html#calendar
>>>
>>> [2] The recognized *calendar *attributes are all lower case. No mention
>>> is made of 'case insensitivity.'
>>>      As an example: the *units *attribute is lower case; UNITS, Units
>>> etc are **not* *recognized.
>>>
>>> [3] See attached script.
>>>
>>> %> ncl test_time_julian.ncl
>>>
>>> ------
>>>
>>> Variable: C
>>> Type: float
>>> Total Size: 24 bytes
>>>             6 values
>>> Number of Dimensions: 2
>>> Dimensions and sizes:    [1] x [6]
>>> Coordinates:
>>> Number Of Attributes: 1
>>>
>>>
>>>
>>>
>>> *calendar :    JULIAN(0,0)    2015(0,1)     5(0,2)    13(0,3)    12*
>>> (0,4)     0
>>> (0,5)     0
>>> (0)    =========
>>>
>>>
>>> Variable: c
>>> Type: float
>>> Total Size: 24 bytes
>>>             6 values
>>> Number of Dimensions: 2
>>> Dimensions and sizes:    [1] x [6]
>>> Coordinates:
>>> Number Of Attributes: 1
>>>
>>>
>>>
>>>
>>> *calendar :    julian(0,0)    2015(0,1)     4(0,2)    30(0,3)    12*
>>> (0,4)     0
>>> (0,5)     0
>>>
>>> The latter matches ferret and (more important) DaveA's hand calculation.
>>>
>>>
>>> On Wed, Nov 15, 2017 at 3:21 PM, Dave Allured - NOAA Affiliate <
>>> dave.allured at noaa.gov> wrote:
>>>
>>>> Denise,
>>>>
>>>> Your sample file uses the Julian calendar.  In my experience the Julian
>>>> calendar is rarely used in climate sciences, and software implementations
>>>> are not well vetted.  The best long term solution might be to switch to the
>>>> Gregorian calendar, if that is not contrary to your current application.
>>>>
>>>> Also your time base is "hours since 0001-01-01 00:00:00".  Using a base
>>>> date before the Julian to Gregorian change in year 1582 exposes you to a
>>>> particular kind of software problem.  You might get better results if you
>>>> can switch to a base date in the near past, such as 1900-1-1 or 2000-1-1,
>>>> regardless of which calendar system is selected.
>>>>
>>>> For what it's worth, my hand calculation for Julian 17657580 hours
>>>> since 1-1-1 0:0:0 gets 2015 April 30 12:00.  This agrees with your ferret
>>>> result.
>>>>
>>>> --Dave
>>>>
>>>>
>>>> On Wed, Nov 15, 2017 at 1:00 PM, Denise Worthen - NOAA Affiliate <
>>>> denise.worthen at noaa.gov> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've used ncra to 'record average' a set of netcdf files. When I look
>>>>> at the file using ferret, the date in each file is correctly interpreted.
>>>>>
>>>>> When I use ncl, the dates in the file are interpreted incorrectly,
>>>>> either as a label (using cd_string) or just printing the value using
>>>>> cd_calendar.
>>>>>
>>>>> I've extracted out the time axis for a single timestep and attached it
>>>>> here. The correct value in this case should be april 30 2015.
>>>>>
>>>>> Using the following commands, it shows the date as 5-13-2015. This is
>>>>> also the label I get when using cd_string to label a plot in the original
>>>>> file.
>>>>>
>>>>> What have I got wrong?
>>>>> Denise.
>>>>>
>>>>>
>>>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/cd_string.ncl"
>>>>>
>>>>> begin
>>>>>
>>>>> f=addfile("timetest.nc","r")
>>>>> timeval=f->time
>>>>> timeUnits = f->time at units
>>>>> timeCalendar = f->time at calendar
>>>>> print(cd_calendar(timeval,0))
>>>>> end
>>>>>
>>>>
>
> _______________________________________________
> ncl-talk mailing list
> ncl-talk at ucar.edu
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20171116/74a95456/attachment.html>