|
| | Time ()=default |
| | Initialize an empty (zero) time value.
|
| |
| | Time (TimeSpan ts) |
| | Initialize time to ts nanoseconds 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 (ValueType secs, int nsecs) |
| | Initialize time to secs (seconds) and nsecs (nanoseconds) summed since 00:00:00 on January 1, 1970 in UTC.
|
| |
| | Time (int year, int month, int day, int hour, int min, int sec, ValueType nsecs, bool local=true) |
| |
| tm | split (bool local, int *nsecpart=0) const |
| | Break up the time to the standard representation, either in UTC (if local is false) or local time (if local is true).
|
| |
| tm | utc (int *nsecpart=0) const |
| | Break up the time to the standard library representation, keeping it in UTC.
|
| |
| tm | local (int *nsecpart=0) const |
| | Break up the time to the standard library representation, converting it first to local time.
|
| |
| int | year (bool local) const |
| | Get the year.
|
| |
| int | month (bool local) const |
| | Get the month, numbered [0,11].
|
| |
| int | day (bool local) const |
| | Get the day of month, numbered [1,31].
|
| |
| int | hour (bool local) const |
| | Get the hour, numbered [0, 23].
|
| |
| int | minute (bool local) const |
| | Get the minute, numbered [0, 59].
|
| |
| int | second (bool local) const |
| | Get the seconds, numbered [0,61] (allowing one or two leap seconds, years with leap seconds can have the time Dec 31, 23:59:60 (or :61).)
|
| |
| int | nsecond () const |
| | Get the nanoseconds.
|
| |
| int | weekday (bool local) const |
| | Get the day of week, numbered [0,6] and starting from Sunday.
|
| |
| bool | isdst (bool local) const |
| | Check whether daylight savings is in effect.
|
| |
| ValueType | utcoffset (int *daylight=0) const |
| | Return the number of nanoseconds that needs to be added to UTC to translate this time to the local time (= nanoseconds east of UTC).
|
| |
| const char * | timezone (int *daylight=0) const |
| | Return the local timezone name that applies at this time value.
|
| |
| Time & | operator+= (const TimeSpan &x) |
| | Add the specified amount to the time.
|
| |
| Time & | operator-= (const TimeSpan &x) |
| | Subtract the specified amount from the time.
|
| |
| ValueType | ns () const |
| | Return the time as nanoseconds since 00:00:00 on January 1, 1970 in UTC.
|
| |
| std::string | format (bool local, std::string spec="%c") const |
| | Format the time using strftime.
|
| |
| std::string | nanoformat (std::size_t minwidth=1, std::size_t maxwidth=9) const |
| | Format the nanosecond fractional part of the time as a string.
|
| |
Based on seal::Time.
Calendar time in nanoseconds since 00:00:00 on January 1, 1970, Coordinated Universal Time (UTC).
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).
- See also
- #TimeInfo for monotonic time not related to the calendar. (Documentation taken from original SEAL class)
- Author
- Marco Clemencic
- Date
- 2005-12-15
Definition at line 232 of file Time.h.
1.13.1