Re: ut_calendar and negative times

Jamie and Harry,

I'll look into this. We've had some other problems with ut_calendar
and the 360, 365, etc type of calendars. I just received a new
version of this code 2 days ago which I'm trying to get it to work
under Udunits-2. I'll check if it fixes this problem.

--Mary

On Jan 13, 2010, at 11:46 AM, Jamie Scott wrote:

> I think this may be a bug. I tried the following on two platforms
> and got two different answers:
>
> mytime=-39615.
> mytime@units="days since 1970-01-01 00:00:0"
> mytime@calendar="360_day"
> date = ut_calendar(mytime,-1)
> print(date)
>
> On my intel Mac running v5.1.1, the answer result is:
> Variable: date
> Type: integer
> Total Size: 4 bytes
> 1 values
> Number of Dimensions: 1
> Dimensions and sizes: [1]
> Coordinates:
> Number Of Attributes: 1
> calendar : 360_day
> (0) 172201
>
> On an intel machine running 64bit r ed hat l swer is:
>
> Variable: date
> Type: integer
> Total Size: 4 bytes
> 1 values
> Number of Dimensions: 1
> Dimensions and sizes: [1]
> Coordinates:
> Number Of Attributes: 1
> calendar : 360_day
> (0) 185912
>
>
> On Jan 13, 2010, at 11:10 AM, ncl-talk-request@ucar.edu wrote:
>
>> Date: Wed, 13 Jan 2010 18:09:44 +0000
>> From: Ian Harris <i.harr ubject: [ncl-talk] ut_calendar and
>> negative times
>> To: NCL_Talk <ncl-talk@ucar.edu>
>> Message-ID: <23F9075B-54BA-4ADB-90D3-5BED56FCCA2D@uea.ac.uk>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Hi,
>>
>> Leaving my 64-bit issues aside for the moment and returning to my
>> trusty G5 Mac, still running NCL 5.1.1 though.
>>
>> I've found what may be a bug in ut_calendar (or may be my idiocy
>> of course).
>>
>> I found that when it encountered negative values in the time
>> field, it gave false results.
>>
>> Here is an example.
>>
>> We have a monthly 'time' variable, the first element and
>> attributes are as follows:
>>
>> ncl 6> print (time(0))
>>
>>
>> Variable: time (subsection)
>> Type: float
>> Total Size: 4 bytes
>> 1 values
>> Number of Dimensions: 1
>> Dimensi ons and >Coordinates:
>> Number Of Attributes: 5
>> time : -39615
>> axis : T
>> calendar : 360_day
>> units : days since 1970-01-01 00:00:0
>> long_name : Time
>> (0) -39615
>>
>> So we see it's 360 day years (that's not unusual for climate model
>> work). The reference day is Jan 1st 1970, and the first time point
>> is -39615.
>>
>> Remember it's monthly data, that's why the number ends in
>> '15' (months are usually represented by a day roughly in the
>> middle of the month).
>>
>> If you examine -39615, it turns out to be 110 years and 15 days
>> (in 360-day years). So the first datum represents Jan 15th 1860,
>> or 'January 1860', which is as expected.
>>
>> But what happens when we give ut_calendar this?
>>
>> ncl 9> date = ut_calendar(ti me(0),-1 rted-space">
>> ncl 10> print(date)
>>
>>
>> Variable: date
>> Type: integer
>> Total Size: 4 bytes
>> 1 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [1]
>> Coordinates:
>> Number Of Attributes: 1
>> calendar : 360_day
>> (0) 172201
>>
>> The date returned is January 1722.
>>
>>
>> So, is this a known problem? Or have UKMO crash-tested ut_calendar
>> with their archiving of the HadGEM model output?
>
> _______________________________________________
> 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
Received on Wed Jan 13 13:22:20 2010