[ncl-talk] calendar_decode2: is this a bug?

Dennis Shea shea at ucar.edu
Wed Nov 19 15:39:02 MST 2014


DaveA is correct. It is best to use "seconds/minutes/hours/days since ...",

cd_calendar is a replacement for ut_calendar.
It supports model calendars.

===========
https://www.ncl.ucar.edu/Document/Functions/Built-in/cd_calendar.shtml

ncl 0> a = 1
ncl 1> a at units = "months since 1600-01-01 00:00:00"
ncl 2> print(cd_calendar(a,0))

Variable: unnamed (return)
Type: float
Total Size: 24 bytes
            6 values
Number of Dimensions: 2
Dimensions and sizes:   [1] x [6]
Coordinates:
Number Of Attributes: 1
  calendar :    standard
(0,0)   1600
(0,1)    2
(0,2)    1
(0,3)    0
(0,4)    0
(0,5)    0


On Wed, Nov 19, 2014 at 2:55 PM, Dave Allured - NOAA Affiliate <
dave.allured at noaa.gov> wrote:

> Stefan,
>
> It is not an NCL bug.  I would call it a design problem.
>
> Since months in the real calendar have different lengths, a unit
> specification of "months since ..." is ambiguous.  Several NCL calendar
> support functions are based on the UDUNITS software package, and UDUNITS
> has chosen a fixed non-integer value for the length a month.  This is the
> reason for your odd result values.
>
> Please refer to the ut_calendar function documentation, in the section
> "Caveats of UDUNITS-2", for more details.  It starts by saying:
>
>    "The length of a month is fixed at 1/12 of a tropical year
>    or 2629743.831225 seconds."
>
> This is the same issue for both UDUNITS-1 and UDUNITS-2 versions.  I think
> this is also discussed somewhere in UDUNITS original documentation:
>
>    http://www.unidata.ucar.edu/software/udunits/
>
> But please notice, this is not really a UDUNITS problem either.  In my
> opinion, best practice is to never use variable length base units such as
> month and year.  Such usage is dangerous and leads to much user confusion
> and subtle errors.  Stick with "days since", "hours since", etc. to avoid
> problems.
>
> There are artificial "model calendars" with fixed length months or years,
> e.g "360_day".  Only in these calendar systems does it make sense to use
> "months since" or "years since".  HTH.
>
> --Dave A.
> Author of calendar_decode2
>
> On Wed, Nov 19, 2014 at 2:00 PM, Stefan Muthers <ncl at z107.de> wrote:
>
>> Dear all,
>>
>> I have a problem with calendar_decode2 and do not know whether this is a
>> bug or whether I maybe missunderstand something.
>>
>> Consider the following example:
>>
>> --------------------------
>>
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_csm.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/calendar_decode2.ncl"
>>
>> a=1
>> a at units = "months since 1600-01-01 00:00:00"
>> printVarSummary(a)
>> ;
>> ;Variable: a
>> ;Type: integer
>> ;Total Size: 4 bytes
>> ;            1 values
>> ;Number of Dimensions: 1
>> ;Dimensions and sizes:   [1]
>> ;Coordinates:
>> ;Number Of Attributes: 1
>> ;units :       months since 1600-01-01 00:00:00
>>
>> print(""+calendar_decode2(a, -5))
>> ;(0,0)   1600
>> ;(0,1)   1
>> ;(0,2)   31
>> ;(0,3)   10
>> ;(0,4)   29
>> ;(0,5)   3
>>
>> --------------------------
>>
>> I would expect the calendar_decode2 function to return 1600-02-01. Why
>> is 1600-01-31 returned here?
>>
>> thanks you and best regards,
>>  Stefan
>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
>
> _______________________________________________
> ncl-talk mailing list
> 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/20141119/383a8a30/attachment.html 


More information about the ncl-talk mailing list