Given a time increment as a real number, and base time and calendar as a character strings, returns time as a time_type variable.
fms_mod
time_manager_mod
get_cal_time (time_increment, units, calendar, permit_calendar_conversion)
| 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] |