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

Data Types
interface	get_cal_time
	Added for mixed precision support. Updates force time_manager math to be done with kind=8 reals _wrap just casts a passed in r4 to r8 and calls r8 version. More...

Functions/Subroutines
character(len=256) function	cut0 (string)

type(time_type) function	get_calendar_time (time_increment, units, calendar, permit_calendar_conversion)
	Calculates what a given calendar time would be after a interval of time. More...

type(time_type) function	get_calendar_time (time_increment, units, calendar, permit_calendar_conversion)
	Calculates what a given calendar time would be after a interval of time. More...

type(time_type) function	get_calendar_time_wrap (time_increment, units, calendar, permit_calendar_conversion)
	For mixed precision support, just casts to passed in increment to r8.

type(time_type) function	get_calendar_time_wrap (time_increment, units, calendar, permit_calendar_conversion)
	For mixed precision support, just casts to passed in increment to r8.

Variables
logical	allow_calendar_conversion =.true.

logical	initialized

logical	is

logical	module

logical	on

logical	this

Detailed Description

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

Data Type Documentation

◆ get_cal_time_mod::get_cal_time

interface get_cal_time_mod::get_cal_time

Added for mixed precision support. Updates force time_manager math to be done with kind=8 reals _wrap just casts a passed in r4 to r8 and calls r8 version.

Definition at line 66 of file get_cal_time.F90.

Private Member Functions
type(time_type) function	get_calendar_time (time_increment, units, calendar, permit_calendar_conversion)
	Calculates what a given calendar time would be after a interval of time. More...

type(time_type) function	get_calendar_time_wrap (time_increment, units, calendar, permit_calendar_conversion)
	For mixed precision support, just casts to passed in increment to r8.

Function/Subroutine Documentation

◆ get_calendar_time() [1/2]

type(time_type) function get_calendar_time	(	real(r8_kind), intent(in)	time_increment,
		character(len=*), intent(in)	units,
		character(len=*), intent(in)	calendar,
		logical, intent(in), optional	permit_calendar_conversion
	)

private

Calculates what a given calendar time would be after a interval of time.

Parameters

time_increment A time interval

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

Parameters

calendar Acceptable values of calendar are: 'noleap' '365_day' '360_day' 'julian' 'thirty_day_months' 'no_calendar'

optional 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.

Definition at line 162 of file get_cal_time.F90.

◆ get_calendar_time() [2/2]

type(time_type) function get_cal_time_mod::get_calendar_time	(	real(r8_kind), intent(in)	time_increment,
		character(len=*), intent(in)	units,
		character(len=*), intent(in)	calendar,
		logical, intent(in), optional	permit_calendar_conversion
	)

private

Calculates what a given calendar time would be after a interval of time.

Parameters

time_increment A time interval

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

Parameters

calendar Acceptable values of calendar are: 'noleap' '365_day' '360_day' 'julian' 'thirty_day_months' 'no_calendar'

optional 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.

Definition at line 162 of file get_cal_time.F90.

Data Types

Functions/Subroutines

Variables

Detailed Description

Data Type Documentation

◆ get_cal_time_mod::get_cal_time

Private Member Functions

Function/Subroutine Documentation

◆ get_calendar_time() [1/2]

◆ get_calendar_time() [2/2]