Classes of the "time" package allow management of the simulation time in FAME.
Classes of the "time" package allow management of the simulation time in FAME.
*[TimeStamp](TimeStamp) a point in simulation time
*[TimeStamp](./TimeStamp) a point in simulation time
*[TimeSpan](TimeSpan) time duration - delta between two points in time
*[TimeSpan](./TimeSpan) time duration - delta between two points in time
*[TimePeriod](TimePeriod) period of time - starting & ending at specific simulation times
*[TimePeriod](./TimePeriod) period of time - starting & ending at specific simulation times
*[TimeOfDay](TimeOfDay) a time duration relative to the start of a day
*[TimeOfDay](./TimeOfDay) a time duration relative to the start of a day
# Goals & Non-Goals
## Goals & Non-Goals
All agents are obliged to use FAME's Time classes to represent time within the simulation context.
All agents are obliged to use FAME's Time classes to represent time within the simulation context.
Time classes are successfully implemented when each TimeStamp has a unique simulation time representation and are cross-simulation consistent.
Time classes are successfully implemented when each TimeStamp has a unique simulation time representation and are cross-simulation consistent.
The time classes are not intended to represent wall-time or ticks, or real-world calendars.
The time classes are not intended to represent wall-time or tick-time events.
## Proposed Solution
# Current Solution
Use class TimeStamp to represent simulated time.
In current AMIRIS simulation time is an "int" bound by definition to a certain real-time hour, i.e. "AMIRIS-time = 0" is the first hour of the year 2006. A fixed time interval between ticks is assumed: hours. Time
TimeStamp has a formatted output that allows an easy conversion to corresponding real-world time.
differences are represented as int as well. If an agent needs a certain time, an int comparison is used. For time intervals, modulo operations are used.
TimeStamps have a unique representation of simulated times based on a variable of type **long**.
The value 0 of this variable represents the first second in the year 2000.
# Proposed Solution
Simulation time assumes: 365 days per year, 24 hours per day and 730 hours per month.
Use class TimeStamp to represent simulated time. TimeStamp has a formatted output that allows an easy conversion to corresponding real-world time. TimeStamps have a unique representation of simulated times based on a variable of type **long**. The value 0 of this variable represents the first second in the year 2000. Simulation time assumes: 365 days per year, 24 hours per day and 730 hours per month. This is not
This is not matching real-world time since leap-years, daylight-savings time and uneven month durations are ignored.
true for real-world time, due to leap-years, summer / winter time and uneven month durations.
Using TimeSpan-objects, TimeStamps can be "shifted" to represent future or past TimeStamps.
TimeStamps can be "shifted" to represent future or past TimeStamps using TimeSpan-objects. TimeSpans can be constructed based on simulation time Intervals. Intervals represent typical simulation time intervals, e.g. days, hours, weeks, etc.
TimeSpans can be constructed based on typical simulation time intervals, e.g., days, hours, weeks.
TimeStamp know of their special simulation time representation: e.g. if they are "the beginning / end of a day, hour, minute, week, month,...)"
## Alternative Solutions
A real-world DateTime library was considered as basis for simulation time.
# Alternative Solutions
It was decided not to use "uneven" real-time, as this hampers the transfer of data from different years due to different year lengths and summer / winter time transitions.
An external DateTime library was considered as basis for simulation time. It was decided not to use "uneven" real-time, as this hampers the transfer of data from different years due to different year lenghts and summer / winter time transitions.
## Impacts
# Cross-Team Impact
|Aspect|Impact|
<table>
|--------|-------|
<colgroup>
|What maintenance effort to keep element running?|very low - defined once|
<colstyle="width: 42%"/>
|What latency caused to the system?|very low - primitive type 'long' needs but 8 Bytes|
<colstyle="width: 57%"/>
|Tightly coupled to:|Agents, Scheduler|
</colgroup>
|Negative consequences?|no 1:1 transfer between real-time and simulated time possible|
<thead>
\ No newline at end of file
<trclass="header">
<th>Impactor</th>
<th>Answers</th>
</tr>
</thead>
<tbody>
<trclass="odd">
<td>What maintenance effort to keep element running?</td>
