QDateTime Class

Detailed Description

A QDateTime object encodes a calendar date and a clock time (a "datetime"). It combines features of the QDate and QTime classes. It can read the current datetime from the system clock. It provides functions for comparing datetimes and for manipulating a datetime by adding a number of seconds, days, months, or years.

QDateTime can describe datetimes with respect to local time, to UTC, to a specified offset from UTC or to a specified time zone, in conjunction with the QTimeZone class. For example, a time zone of "Europe/Berlin" will apply the daylight-saving rules as used in Germany since 1970. In contrast, an offset from UTC of +3600 seconds is one hour ahead of UTC (usually written in ISO standard notation as "UTC+01:00"), with no daylight-saving offset or changes. When using either local time or a specified time zone, time-zone transitions such as the starts and ends of daylight-saving time (DST; but see below) are taken into account. The choice of system used to represent a datetime is described as its "timespec".

A QDateTime object is typically created either by giving a date and time explicitly in the constructor, or by using a static function such as currentDateTime() or fromMSecsSinceEpoch(). The date and time can be changed with setDate() and setTime(). A datetime can also be set using the setMSecsSinceEpoch() function that takes the time, in milliseconds, since 00:00:00 on January 1, 1970. The fromString() function returns a QDateTime, given a string and a date format used to interpret the date within the string.

QDateTime::currentDateTime() returns a QDateTime that expresses the current time with respect to local time. QDateTime::currentDateTimeUtc() returns a QDateTime that expresses the current time with respect to UTC.

The date() and time() functions provide access to the date and time parts of the datetime. The same information is provided in textual format by the toString() function.

QDateTime provides a full set of operators to compare two QDateTime objects, where smaller means earlier and larger means later.

You can increment (or decrement) a datetime by a given number of milliseconds using addMSecs(), seconds using addSecs(), or days using addDays(). Similarly, you can use addMonths() and addYears(). The daysTo() function returns the number of days between two datetimes, secsTo() returns the number of seconds between two datetimes, and msecsTo() returns the number of milliseconds between two datetimes. These operations are aware of daylight-saving time (DST) and other time-zone transitions, where applicable.

Use toTimeSpec() to express a datetime in local time or UTC, toOffsetFromUtc() to express in terms of an offset from UTC, or toTimeZone() to express it with respect to a general time zone. You can use timeSpec() to find out what time-spec a QDateTime object stores its time relative to. When that is Qt::TimeZone, you can use timeZone() to find out which zone it is using.

Remarks

No Year 0

There is no year 0. Dates in that year are considered invalid. The year -1 is the year "1 before Christ" or "1 before current era." The day before 1 January 1 CE is 31 December 1 BCE.

Range of Valid Dates

The range of values that QDateTime can represent is dependent on the internal storage implementation. QDateTime is currently stored in a qint64 as a serial msecs value encoding the date and time. This restricts the date range to about +/- 292 million years, compared to the QDate range of +/- 2 billion years. Care must be taken when creating a QDateTime with extreme values that you do not overflow the storage. The exact range of supported values varies depending on the Qt::TimeSpec and time zone.

Use of Timezones

QDateTime uses the system's time zone information to determine the current local time zone and its offset from UTC. If the system is not configured correctly or not up-to-date, QDateTime will give wrong results.

QDateTime likewise uses system-provided information to determine the offsets of other timezones from UTC. If this information is incomplete or out of date, QDateTime will give wrong results. See the QTimeZone documentation for more details.

On modern Unix systems, this means QDateTime usually has accurate information about historical transitions (including DST, see below) whenever possible. On Windows, where the system doesn't support historical timezone data, historical accuracy is not maintained with respect to timezone transitions, notably including DST.

Daylight-Saving Time (DST)

QDateTime takes into account transitions between Standard Time and Daylight-Saving Time. For example, if the transition is at 2am and the clock goes forward to 3am, then there is a "missing" hour from 02:00:00 to 02:59:59.999 which QDateTime considers to be invalid. Any date arithmetic performed will take this missing hour into account and return a valid result. For example, adding one minute to 01:59:59 will get 03:00:00.

The range of valid dates taking DST into account is 1970-01-01 to the present, and rules are in place for handling DST correctly until 2037-12-31, but these could change. For dates after 2037, QDateTime makes a best guess using the rules for year 2037, but we can't guarantee accuracy; indeed, for any future date, the time-zone may change its rules before that date comes around. For dates before 1970, QDateTime doesn't take DST changes into account, even if the system's time zone database provides that information, although it does take into account changes to the time-zone's standard offset, where this information is available.

Offsets From UTC

There is no explicit size restriction on an offset from UTC, but there is an implicit limit imposed when using the toString() and fromString() methods which use a [+|-]hh:mm format, effectively limiting the range to +/- 99 hours and 59 minutes and whole minutes only. Note that currently no time zone lies outside the range of +/- 14 hours.