PUBLIC INTERFACE ~ PUBLIC DATA ~ PUBLIC ROUTINES ~ NAMELIST ~ DIAGNOSTIC FIELDS ~ ERROR MESSAGES ~ REFERENCES ~ NOTES

## Module get_cal_time_mod

Contact: fms
Reviewers:
Change History: WebCVS Log

#### OVERVIEW

Given a time increment as a real number, and base time and calendar as a character strings, returns time as a time_type variable.

#### OTHER MODULES USED

             fms_mod
    time_manager_mod

#### PUBLIC INTERFACE

get_cal_time:

#### PUBLIC DATA

None.

#### PUBLIC ROUTINES

1. #### get_cal_time

       get_cal_time (time_increment, units, calendar, permit_calendar_conversion)

   DESCRIPTION
   INPUT

     `time_increment` | A time interval. [real]
     `units` | Examples of acceptable values of units: 'days since 1980-01-01 00:00:00', 'hours since 1980-1-1 0:0:0', 'minutes since 0001-4-12' The first word in the string must be 'years', 'months', 'days', 'hours', 'minutes' or 'seconds'. The second word must be 'since' year number must occupy 4 spaces. Number of months, days, hours, minutes, seconds may occupy 1 or 2 spaces year, month and day must be separated by a '-' hour, minute, second must be separated by a ':' hour, minute, second are optional. If not present then zero is assumed. Because months are not equal increments of time, and, for julian calendar, neither are years, the 'years since' and 'month since' cases deserve further explaination. When 'years since' is used: The year number is increased by floor(time_increment) to obtain a time T1. The year number is increased by floor(time_increment)+1 to obtain a time T2. The time returned is T1 + (time_increment-floor(time_increment))*(T2-T1). When 'months since' is used: The month number is increased by floor(time_increment). If it falls outside to range 1 to 12 then it is adjusted along with the year number to convert to a valid date. The number of days in the month of this date is used to compute the time interval of the fraction. That is: The month number is increased by floor(time_increment) to obtain a time T1. delt = the number of days in the month in which T1 falls. The time returned is T1 + ((time_increment-floor(time_increment))*delt. Two of the consequences of this scheme should be kept in mind. -- The time since should not be from the 29'th to 31'st of a month, since an invalid date is likely to result, triggering an error stop. -- When time since is from the begining of a month, the fraction of a month will never advance into the month after that which results from only the whole number. When NO_CALENDAR is in effect, units attribute must specify a starting day and second, with day number appearing first Example: 'days since 100 0' Indicates 100 days 0 seconds [character]
     `calendar` | Acceptable values of calendar are: 'noleap' '365_day' '360_day' 'julian' 'thirty_day_months' 'no_calendar' [character]
     `permit_calendar_conversion` | It is sometimes desirable to allow the value of the intent(in) argument "calendar" to be different than the calendar in use by time_manager_mod. If this is not desirable, then the optional variable "permit_calendar_conversion" should be set to .false. so as to allow an error check. When calendar conversion is done, the time returned is the time in the time_manager's calendar, but corresponds to the date computed using the input calendar. For example, suppose the time_manager is using the julian calendar and the values of the input arguments of get_cal_time are: time_increment = 59.0 units = 'days since 1980-1-1 00:00:00' calendar = 'noleap' Because it will use the noleap calendar to calculate the date, get_cal_time will return value of time for midnight March 1 1980, but it will be time in the julian calendar rather than the noleap calendar. It will never return a value of time corresponding to anytime during the day Feb 29. Another example: Suppose the time_manager is using either the noleap or julian calendars, and the values of the input arguments are: time_increment = 30.0 units = 'days since 1980-1-1' calendar = 'thirty_day_months' In this case get_cal_time will return the value of time for Feb 1 1980 00:00:00, but in the time_manager's calendar. Calendar conversion may result in a fatal error when the input calendar type is a calendar that has more days per year than that of the time_manager's calendar. For example, if the input calendar type is julian and the time_manager's calendar is thirty_day_months, then get_cal_time will try to convert Jan 31 to a time in the thirty_day_months calendar, resulting in a fatal error. Note: this option was originally coded to allow noleap calendar as input when the julian calendar was in effect by the time_manager. [logical, optional]

#### NAMELIST

&get_cal_time_nml

`allow_calendar_conversion`

This sets the default value of the optional argument named "permit_calendar_conversion" of get_cal_time. This namelist is deprecated as of the memphis release. If calendar conversion is not desired, then it is recommended that permit_calendar_conversion be present in the call to get_cal_time and that it be set to .false.
[logical, default: .true.]

#### DATA SETS

None.

#### ERROR MESSAGES

None.

top