<div dir="ltr">Stefan,<div><br></div><div>It is not an NCL bug. I would call it a design problem.</div><div><br></div><div>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.</div><br>Please refer to the ut_calendar function documentation, in the section "Caveats of UDUNITS-2", for more details. It starts by saying:<br><br> "The length of a month is fixed at 1/12 of a tropical year<div> or 2629743.831225 seconds."</div><div><br></div><div>This is the same issue for both UDUNITS-1 and UDUNITS-2 versions. I think this is also discussed somewhere in UDUNITS original documentation:</div><div><br></div><div> <a href="http://www.unidata.ucar.edu/software/udunits/" target="_blank">http://www.unidata.ucar.edu/software/udunits/</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>--Dave A.</div><div>Author of calendar_decode2</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 2:00 PM, Stefan Muthers <span dir="ltr"><<a href="mailto:ncl@z107.de" target="_blank">ncl@z107.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I have a problem with calendar_decode2 and do not know whether this is a<br>
bug or whether I maybe missunderstand something.<br>
<br>
Consider the following example:<br>
<br>
--------------------------<br>
<br>
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl"<br>
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_csm.ncl"<br>
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"<br>
load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/calendar_decode2.ncl"<br>
<br>
a=1<br>
a@units = "months since 1600-01-01 00:00:00"<br>
printVarSummary(a)<br>
;<br>
;Variable: a<br>
;Type: integer<br>
;Total Size: 4 bytes<br>
; 1 values<br>
;Number of Dimensions: 1<br>
;Dimensions and sizes: [1]<br>
;Coordinates:<br>
;Number Of Attributes: 1<br>
;units : months since 1600-01-01 00:00:00<br>
<br>
print(""+calendar_decode2(a, -5))<br>
;(0,0) 1600<br>
;(0,1) 1<br>
;(0,2) 31<br>
;(0,3) 10<br>
;(0,4) 29<br>
;(0,5) 3<br>
<br>
--------------------------<br>
<br>
I would expect the calendar_decode2 function to return 1600-02-01. Why<br>
is 1600-01-31 returned here?<br>
<br>
thanks you and best regards,<br>
Stefan<br>
<br>
<br>
_______________________________________________<br>
ncl-talk mailing list<br>
List instructions, subscriber options, unsubscribe:<br>
<a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a><br>
</blockquote></div><br></div>