Re: ut_calendar and negative times

From: Jamie Scott <James.D.Scott_at_nyahnyahspammersnyahnyah>
Date: Wed Jan 13 2010 - 11:46:49 MST

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 red hat linux (ncl v5.1.1), the
answer 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.harris@uea.ac.uk>
> Subject: 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
> Dimensions and sizes: [1]
> 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(time(0),-1)
> 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
Received on Wed Jan 13 11:46:57 2010

This archive was generated by hypermail 2.1.8 : Thu Feb 18 2010 - 10:33:29 MST