|
|
|
#include <Iguana/Utilities/classlib/utils/Time.h>
Public Types | |
| typedef TimeConst::TimeValue | ValueType |
Public Member Functions | |
| int | day (bool local) const |
| std::string | format (bool local, const std::string &spec) const |
| int | hour (bool local) const |
| bool | isdst (bool local) const |
| tm | local (long *nsecpart=0) const |
| int | minute (bool local) const |
| int | month (bool local) const |
| std::string | nanoformat (int minwidth=1, int maxwidth=9) const |
| ValueType | ns (void) const |
| Return the time as nanoseconds since 00:00:00 on January 1, 1970 in UTC. | |
| long | nsecond (void) const |
| Time & | operator+= (TimeSpan x) |
| Add the specified amount to the time. | |
| Time & | operator-= (TimeSpan x) |
| Subtract the specified amount from the time. | |
| int | second (bool local) const |
| tm | split (bool local, long *nsecpart=0) const |
| Time (int year, int month, int day, int hour, int min, int sec, ValueType nsecs, bool local=true) | |
| Time (ValueType secs, ValueType nsecs) | |
| Initialize time to secs (seconds) and nsecs (nanoseconds) summed since 00:00:00 on January 1, 1970 in UTC. | |
| Time (ValueType nsecs) | |
| Initialize time to nsecs nanoseconds since 00:00:00 on January 1, 1970 in UTC. | |
| Time (TimeSpan ts) | |
| Initialize time to ts nanoseconds since 00:00:00 on January 1, 1970 in UTC. | |
| Time (void) | |
| Initialize an empty (zero) time value. | |
| const char * | timezone (int *daylight=0) const |
| tm | utc (long *nsecpart=0) const |
| ValueType | utcoffset (int *daylight=0) const |
| int | weekday (bool local) const |
| int | year (bool local) const |
Static Public Member Functions | |
| static Time | build (bool local, const tm &base, TimeSpan diff=0) |
| static Time | current (void) |
| static Time | epoch (void) |
| Return the time for the epoch (= zero time). | |
| static Time | fromDosDate (unsigned dosDate) |
| static bool | isLeap (int year) |
| Check if the year is a leap-year. | |
| static unsigned | toDosDate (Time time) |
Private Attributes | |
| ValueType | m_nsecs |
Friends | |
| class | TimeSpan |
Time is represented internally as UTC time, but it can also be converted to the local time as necessary. Most methods take an argument flag local to indicate which time interpretation is desired by the client, and automatically perform the necessary adjustments. The client can also find out about the difference between UTC time and local time using the utcoffset() method, and the time zone name with timezone() method. Both allow the client to discover whether daylight savings is in effect.
The native representation of Time is not well suited for human handling of time. Time provides access in more convenient terms such as year(), month() and day(); more are available through conversion into a TimeSpan. Time can also be converted to and from ISO C standard tm structure. Note however that unlike C's mktime() which always assumes tm in local time, Time fully supports all conversions between local and universal time. Thus it is possible for example to build() a UTC time directly from a tm.
Time behaves as an integral type. Differences in time values are represented as a TimeSpan. Usual integral arithmetic works with both types. Output works in general as any other integral type, however since the ValueType can be a wide type, it may be poorly supported by the iostream; if so, including the LongLong.h header will help. Note that the output value will usually be very large as Time is represented in nanoseconds, not seconds! When constructing Time values in seconds, such as when reading in, do remember to use the two-argument constructor taking seconds and nanoseconds instead of the default single-argument one.
Time can be formatted into a string using the format() method, which uses the versatile strftime() function. Since the latter works on seconds at best (through a struct tm), the subsecond part cannot be formatted; the nanoformat() method is provided to overcome this limitation. To combine format() and nanoformat() output use a suitable StringFormat pattern.
Time is linked to the system's concept of calendar time and is therefore may not be linear nor monotonic. System time can jump arbitrarily in either direction as real time clock is corrected or the system is suspended. The local time may also jump due to daylight savings. The process' ability to sample system time can be limited for reasons such as getting swapped out. TimeInfo provides an alternative time measurement facility not linked to calendar and guaranteed to grow monotonically -- though not always linearly. Note that few systems actually provide wall-clock time in nanosecond resolution. Not all system provide an interface to get time at that resolution, let alone track it so precisely.
Because of the time warp issues, scheduling events using Time is not straightforward. Application code should understand whether it is dealing with concrete or abstract calendar calculations, and how the events it schedules are linked to wall clock time.
For calculations on concrete calendar as perceived by people use local() after plain Time and TimeSpan integer arithmetic. The method accounts for timezone and daylight savings definitions. To schedule events use build() to derive times from local() time to get values comparable to the system time returned by current(). The applications should know whether events are scheduled in UTC or local time---"meeting at 9:00 on Wednesday morning" when the device switches timezones may be known to be at 9:00 in the new timezone (= locked to local time), or in the timezone where the event was created (= locked to UTC). The build() and split() methods allow either format to be used, the application just needs to know which one to use. It is also easy to convert between the two using utcoffset().
For calculations using an abstract calendar, without timezone or daylight savings, use Time in its native UTC representation and integer arithmetic with Time and TimeSpan. Do note however that "T + 24 hours" may not be the same hour the next day in the local calendar time -- timezone changes and daylight savings make a difference. This may require the application to accept as user input exception rules to its usual calendar calculations.
To schedule events, one should choose between three choices: UTC time, local time, or delta time. For the first two cases system time should be polled regularly to see if any of the recorded events have expired. It is not a good idea to sleep until the next scheduled event, as the system time may jump during the nap; instead sleep small increments, recheck the current time after each nap and trigger the events that have expired. A policy must be applied when the system time warps; this can happen both forwards and backwards with both local and UTC time (daylight savings or timezone changes for mobile devices are common local time change reasons, but the system time can be updated for any reason, e.g. when the real time clock is wrong, or if the system is suspended for a long time). Some events should be executed only once in case of time warps backwards. If the time jumps forwards, several events may need to be dealt with in one go. In either case the application should guard against major time changes: long system suspends, moving mobile devices and major time updates may result in a large number of "missed" events. One possibility is to provide a user-configurable "excessive time drift limit" (e.g. N hours): if time changes by more than that, missed events are not triggered.
For the final case of using delta times, sort upcoming events by their deltas from the previous event---not by the time they are anticipated to occur. Capture current time before and after the sleep and pull events off the queue based on the difference (the sleep time may exceed the requested time). Either guard against long time warps like suspends or schedule timer events cautiously. Using TimeInfo as schedule base solves such issues simply. To cope with backward system time jumps when using Time as schedule base, assume that sleeps always last at least the requested time; if the time delta over the nap is less than the requested, assume time warp (this is not foolproof against interrupted system calls but works for many event scheduling situations).
Definition at line 191 of file Time.h.
| lat::Time::Time | ( | void | ) | [inline] |
| lat::Time::Time | ( | TimeSpan | ts | ) | [inline] |
| lat::Time::Time | ( | ValueType | nsecs | ) | [inline] |
| lat::Time::Time | ( | int | year, | |
| int | month, | |||
| int | day, | |||
| int | hour, | |||
| int | min, | |||
| int | sec, | |||
| ValueType | nsecs, | |||
| bool | local = true | |||
| ) |
Referenced by DQMService::flush().
| std::string lat::Time::format | ( | bool | local, | |
| const std::string & | spec | |||
| ) | const |
| static Time lat::Time::fromDosDate | ( | unsigned | dosDate | ) | [static] |
| tm lat::Time::local | ( | long * | nsecpart = 0 |
) | const |
| Time::ValueType lat::Time::ns | ( | void | ) | const [inline] |
Return the time as nanoseconds since 00:00:00 on January 1, 1970 in UTC.
Definition at line 281 of file Time.h.
References m_nsecs.
Referenced by lat::operator *(), lat::operator!(), lat::operator!=(), lat::operator%(), lat::operator+(), lat::operator-(), lat::operator/(), lat::operator<(), lat::operator<=(), lat::operator==(), lat::operator>(), and lat::operator>=().
00282 { return m_nsecs; }
| long lat::Time::nsecond | ( | void | ) | const |
| tm lat::Time::split | ( | bool | local, | |
| long * | nsecpart = 0 | |||
| ) | const |
| const char* lat::Time::timezone | ( | int * | daylight = 0 |
) | const |
| static unsigned lat::Time::toDosDate | ( | Time | time | ) | [static] |
| tm lat::Time::utc | ( | long * | nsecpart = 0 |
) | const |
ValueType lat::Time::m_nsecs [private] |
1.5.4