PySide6.QtCore.QDateTime

class QDateTime

The QDateTime class provides date and time functions. More

Synopsis

Methods

Static functions

Note

This documentation may contain snippets that were automatically translated from C++ to Python. We always welcome contributions to the snippet translation. If you see an issue with the translation, you can also let us know by creating a ticket on https:/bugreports.qt.io/projects/PYSIDE

Detailed Description

A QDateTime object encodes a calendar date and a clock time (a “datetime”) in accordance with a time representation. 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 . Each of these time representations can be encapsulated in a suitable instance of the QTimeZone class. For example, a time zone of “Europe/Berlin” will apply the daylight-saving rules as used in Germany. In contrast, a fixed 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 complications. When using either local time or a specified time zone, time-zone transitions (see below ) are taken into account. A QDateTime ‘s timeSpec() will tell you which of the four types of time representation is in use; its timeRepresentation() provides a full description of that time representation, as a QTimeZone .

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 the start, in UTC, of the year 1970. The fromString() function returns a QDateTime , given a string and a date format used to interpret the date within the string.

currentDateTime() returns a QDateTime that expresses the current date and time with respect to a specific time representation, such as local time (its default). currentDateTimeUtc() returns a QDateTime that expresses the current date and time with respect to UTC; it is equivalent to QDateTime::currentDateTime(QTimeZone::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 toTimeZone() to re-express a datetime in terms of a different time representation. By passing a lightweight QTimeZone that represents local time, UTC or a fixed offset from UTC, you can convert the datetime to use the corresponding time representation; or you can pass a full time zone (whose timeSpec() is Qt::TimeZone) to use that instead.

Remarks

Note

QDateTime does not account for leap seconds.

Note

All conversion to and from string formats is done using the C locale. For localized conversions, see QLocale .

Note

There is no year 0 in the Gregorian calendar. Dates in that year are considered invalid. The year -1 is the year “1 before Christ” or “1 before common era.” The day before 1 January 1 CE is 31 December 1 BCE.

Note

Using local time (the default) or a specified time zone implies a need to resolve any issues around transitions . As a result, operations on such QDateTime instances (notably including constructing them) may be more expensive than the equivalent when using UTC or a fixed offset from it.

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 time representation used.

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. However, building Qt with the ICU library will equip QTimeZone with the same timezone database as is used on Unix.

Timezone transitions

QDateTime takes into account timezone transitions, both the transitions between Standard Time and Daylight-Saving Time (DST) and the transitions that arise when a zone changes its standard offset. 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. Such a transition is known as a “spring forward” and the times skipped over have no meaning. When a transition goes the other way, known as a “fall back”, a time interval is repeated, first in the old zone (usually DST), then in the new zone (usually Standard Time), so times in this interval are ambiguous.

Some zones use “reversed” DST, using standard time in summer and daylight-saving time (with a lowered offset) in winter. For such zones, the spring forward still happens in spring and skips an hour, but is a transition out of daylight-saving time, while the fall back still repeats an autumn hour but is a transition to daylight-saving time.

When converting from a UTC time (or a time at fixed offset from UTC), there is always an unambiguous valid result in any timezone. However, when combining a date and time to make a datetime, expressed with respect to local time or a specific time-zone, the nominal result may fall in a transition, making it either invalid or ambiguous. Methods where this situation may arise take a resolve parameter: this is always ignored if the requested datetime is valid and unambiguous. See TransitionResolution for the options it lets you control. Prior to Qt 6.7, the equivalent of its LegacyBehavior was selected.

For a spring forward’s skipped interval, interpreting the requested time with either offset yields an actual time at which the other offset was in use; so passing TransitionResolution::RelativeToBefore for resolve will actually result in a time after the transition, that would have had the requested representation had the transition not happened. Likewise, TransitionResolution::RelativeToAfter for resolve results in a time before the transition, that would have had the requested representation, had the transition happened earlier.

When QDateTime performs arithmetic, as with addDay() or addSecs() , it takes care to produce a valid result. For example, on a day when there is a spring forward from 02:00 to 03:00, adding one second to 01:59:59 will get 03:00:00. Adding one day to 02:30 on the preceding day will get 03:30 on the day of the transition, while subtracting one day, by calling addDay(-1), to 02:30 on the following day will get 01:30 on the day of the transition. While addSecs() will deliver a time offset by the given number of seconds, addDays() adjusts the date and only adjusts time if it would otherwise get an invalid result. Applying addDays(1) to 03:00 on the day before the spring-forward will simply get 03:00 on the day of the transition, even though the latter is only 23 hours after the former; but addSecs(24 * 60 * 60) will get 04:00 on the day of the transition, since that’s 24 hours later. Typical transitions make some days 23 or 25 hours long.

For datetimes that the system time_t can represent (from 1901-12-14 to 2038-01-18 on systems with 32-bit time_t; for the full range QDateTime can represent if the type is 64-bit), the standard system APIs are used to determine local time’s offset from UTC. For datetimes not handled by these system APIs (potentially including some within the time_t range), systemTimeZone() is used, if available, or a best effort is made to estimate. In any case, the offset information used depends on the system and may be incomplete or, for past times, historically inaccurate. Furthermore, for future dates, the local time zone’s offsets and DST rules may change before that date comes around.

Whole day transitions

A small number of zones have skipped or repeated entire days as part of moving The International Date Line across themselves. For these, daysTo() will be unaware of the duplication or gap, simply using the difference in calendar date; in contrast, msecsTo() and secsTo() know the true time interval. Likewise, addMSecs() and addSecs() correspond directly to elapsed time, where addDays() , addMonths() and addYears() follow the nominal calendar, aside from where landing in a gap or duplication requires resolving an ambiguity or invalidity due to a duplication or omission.

Note

Days “lost” during a change of calendar, such as from Julian to Gregorian, do not affect QDateTime . Although the two calendars describe dates differently, the successive days across the change are described by consecutive QDate instances, each one day later than the previous, as described by either calendar or by their toJulianDay() values. In contrast, a zone skipping or duplicating a day is changing its description of time, not date, for all that it does so by a whole 24 hours.

Offsets From UTC

Offsets from UTC are measured in seconds east of Greenwich. The moment described by a particular date and time, such as noon on a particular day, depends on the time representation used. Those with a higher offset from UTC describe an earlier moment, and those with a lower offset a later moment, by any given combination of date and time.

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 has an offset outside the range of ±14 hours and all known offsets are multiples of five minutes. Historical time zones have a wider range and may have offsets including seconds; these last cannot be faithfully represented in strings.

See also

QDate QTime QTimeZone

class TransitionResolution

This enumeration is used to resolve datetime combinations which fall in Timezone transitions .

When constructing a datetime, specified in terms of local time or a time-zone that has daylight-saving time, or revising one with setDate() , setTime() or setTimeZone() , the given parameters may imply a time representation that either has no meaning or has two meanings in the zone. Such time representations are described as being in the transition. In either case, we can simply return an invalid datetime, to indicate that the operation is ill-defined. In the ambiguous case, we can alternatively select one of the two times that could be meant. When there is no meaning, we can select a time either side of it that might plausibly have been meant. For example, when advancing from an earlier time, we can select the time after the transition that is actually the specified amount of time after the earlier time in question. The options specified here configure how such selection is performed.

Constant

Description

QDateTime.TransitionResolution.Reject

Treat any time in a transition as invalid. Either it really is, or it is ambiguous.

QDateTime.TransitionResolution.RelativeToBefore

Selects a time as if stepping forward from a time before the transition. This interprets the requested time using the offset in effect before the transition and, if necessary, converts the result to the offset in effect at the resulting time.

QDateTime.TransitionResolution.RelativeToAfter

Select a time as if stepping backward from a time after the transition. This interprets the requested time using the offset in effect after the transition and, if necessary, converts the result to the offset in effect at the resulting time.

QDateTime.TransitionResolution.PreferBefore

Selects a time before the transition,

QDateTime.TransitionResolution.PreferAfter

Selects a time after the transition.

QDateTime.TransitionResolution.PreferStandard

Selects a time on the standard time side of the transition.

QDateTime.TransitionResolution.PreferDaylightSaving

Selects a time on the daylight-saving-time side of the transition.

QDateTime.TransitionResolution.LegacyBehavior

An alias for RelativeToBefore, which is used as default for TransitionResolution parameters, as this most closely matches the behavior prior to Qt 6.7.

For addDays() , addMonths() or addYears() , the behavior is and (mostly) was to use RelativeToBefore if adding a positive adjustment and RelativeToAfter if adding a negative adjustment.

Note

In time zones where daylight-saving increases the offset from UTC in summer (known as “positive DST”), PreferStandard is an alias for RelativeToAfter and PreferDaylightSaving for RelativeToBefore. In time zones where the daylight-saving mechanism is a decrease in offset from UTC in winter (known as “negative DST”), the reverse applies, provided the operating system reports - as it does on most platforms - whether a datetime is in DST or standard time. For some platforms, where transition times are unavailable even for TimeZone datetimes, QTimeZone is obliged to presume that the side with lower offset from UTC is standard time, effectively assuming positive DST.

The following tables illustrate how a QDateTime constructor resolves a request for 02:30 on a day when local time has a transition between 02:00 and 03:00, with a nominal standard time LST and daylight-saving time LDT on the two sides, in the various possible cases. The transition type may be to skip an hour or repeat it. The type of transition and value of a parameter resolve determine which actual time on the given date is selected. First, the common case of positive daylight-saving, where:

Before

02:00–03:00

After

resolve

selected

LST

skip

LDT

RelativeToBefore

03:30 LDT

LST

skip

LDT

RelativeToAfter

01:30 LST

LST

skip

LDT

PreferBefore

01:30 LST

LST

skip

LDT

PreferAfter

03:30 LDT

LST

skip

LDT

PreferStandard

01:30 LST

LST

skip

LDT

PreferDaylightSaving

03:30 LDT

LDT

repeat

LST

RelativeToBefore

02:30 LDT

LDT

repeat

LST

RelativeToAfter

02:30 LST

LDT

repeat

LST

PreferBefore

02:30 LDT

LDT

repeat

LST

PreferAfter

02:30 LST

LDT

repeat

LST

PreferStandard

02:30 LST

LDT

repeat

LST

PreferDaylightSaving

02:30 LDT

Second, the case for negative daylight-saving, using LDT in winter and skipping an hour to transition to LST in summer, then repeating an hour at the transition back to winter:

LDT

skip

LST

RelativeToBefore

03:30 LST

LDT

skip

LST

RelativeToAfter

01:30 LDT

LDT

skip

LST

PreferBefore

01:30 LDT

LDT

skip

LST

PreferAfter

03:30 LST

LDT

skip

LST

PreferStandard

03:30 LST

LDT

skip

LST

PreferDaylightSaving

01:30 LDT

LST

repeat

LDT

RelativeToBefore

02:30 LST

LST

repeat

LDT

RelativeToAfter

02:30 LDT

LST

repeat

LDT

PreferBefore

02:30 LST

LST

repeat

LDT

PreferAfter

02:30 LDT

LST

repeat

LDT

PreferStandard

02:30 LST

LST

repeat

LDT

PreferDaylightSaving

02:30 LDT

Reject can be used to prompt relevant QDateTime APIs to return an invalid datetime object so that your code can deal with transitions for itself, for example by alerting a user to the fact that the datetime they have selected is in a transition interval, to offer them the opportunity to resolve a conflict or ambiguity. Code using this may well find the other options above useful to determine relevant information to use in its own (or the user’s) resolution. If the start or end of the transition, or the moment of the transition itself, is the right resolution, QTimeZone ‘s transition APIs can be used to obtain that information. You can determine whether the transition is a repeated or skipped interval by using secsTo() to measure the actual time between noon on the previous and following days. The result will be less than 48 hours for a skipped interval (such as a spring-forward) and more than 48 hours for a repeated interval (such as a fall-back).

Note

When a resolution other than Reject is specified, a valid QDateTime object is returned, if possible. If the requested date-time falls in a gap, the returned date-time will not have the time() requested - or, in some cases, the date() , if a whole day was skipped. You can thus detect when a gap is hit by comparing date() and time() to what was requested.

Relation to other datetime software

The Python programming language’s datetime APIs have a fold parameter that corresponds to RelativeToBefore (fold = True) and RelativeToAfter (fold = False).

The Temporal proposal to replace JavaScript’s Date offers four options for how to resolve a transition, as value for a disambiguation parameter. Its 'reject' raises an exception, which roughly corresponds to Reject producing an invalid result. Its 'earlier' and 'later' options correspond to PreferBefore and PreferAfter. Its 'compatible' option corresponds to RelativeToBefore (and Python’s fold = True).

See also

Timezone transitions TransitionResolution

Added in version 6.7.

class YearRange

This enumerated type describes the range of years (in the Gregorian calendar) representable by QDateTime :

Constant

Description

QDateTime.YearRange.First

The later parts of this year are representable

QDateTime.YearRange.Last

The earlier parts of this year are representable

All dates strictly between these two years are also representable. Note, however, that the Gregorian Calendar has no year zero.

Note

QDate can describe dates in a wider range of years. For most purposes, this makes little difference, as the range of years that QDateTime can support reaches 292 million years either side of 1970.

See also

isValid() QDate

__init__()

Constructs a null datetime, nominally using local time.

A null datetime is invalid, since its date and time are invalid.

__init__(other)
Parameters:

otherQDateTime

Constructs a copy of the other datetime.

__init__(date, time[, resolve=QDateTime.TransitionResolution.LegacyBehavior])
Parameters:

This is an overloaded function.

Constructs a datetime with the given date and time, using local time.

If date is valid and time is not, midnight will be used as the time. If date and time describe a moment close to a transition for local time, resolve controls how that situation is resolved.

Note

Prior to Qt 6.7, the version of this function lacked the resolve parameter so had no way to resolve the ambiguities related to transitions.

__init__(date, time, spec[, offsetSeconds=0])
Parameters:

Note

This function is deprecated.

Use QDateTime(date, time) or QDateTime(date, time, QTimeZone::fromSecondsAheadOfUtc(offsetSeconds)).

Constructs a datetime with the given date and time, using the time representation implied by spec and offsetSeconds seconds.

If date is valid and time is not, the time will be set to midnight.

If spec is not OffsetFromUTC then offsetSeconds will be ignored. If spec is OffsetFromUTC and offsetSeconds is 0 then the timeSpec() will be set to UTC , i.e. an offset of 0 seconds.

If spec is TimeZone then the spec will be set to LocalTime , i.e. the current system time zone. To create a TimeZone datetime use the correct constructor.

If date lies outside the range of dates representable by QDateTime , the result is invalid. If spec is LocalTime and the system’s time-zone skipped over the given date and time, the result is invalid.

__init__(date, time, timeZone[, resolve=QDateTime.TransitionResolution.LegacyBehavior])
Parameters:

Constructs a datetime with the given date and time, using the time representation described by timeZone.

If date is valid and time is not, the time will be set to midnight. If timeZone is invalid then the datetime will be invalid. If date and time describe a moment close to a transition for timeZone, resolve controls how that situation is resolved.

Note

Prior to Qt 6.7, the version of this function lacked the resolve parameter so had no way to resolve the ambiguities related to transitions.

__init__(year, month, day, h, m, s)
Parameters:
  • year – int

  • month – int

  • day – int

  • h – int

  • m – int

  • s – int

__init__(year, month, day, h, m, s, ms[, spec=Qt.LocalTime])
Parameters:
  • year – int

  • month – int

  • day – int

  • h – int

  • m – int

  • s – int

  • ms – int

  • specTimeSpec

__init__(year, month, day, h, m, s, ms[, spec=Qt.LocalTime])
Parameters:
  • year – int

  • month – int

  • day – int

  • h – int

  • m – int

  • s – int

  • ms – int

  • spec – int

__reduce__()
Return type:

str

__repr__()
Return type:

str

addDays(days)
Parameters:

days – int

Return type:

QDateTime

Returns a QDateTime object containing a datetime ndays days later than the datetime of this object (or earlier if ndays is negative).

If the timeSpec() is LocalTime or TimeZone and the resulting date and time fall in the Standard Time to Daylight-Saving Time transition hour then the result will be just beyond this gap, in the direction of change. If the transition is at 2am and the clock goes forward to 3am, the result of aiming between 2am and 3am will be adjusted to fall before 2am (if ndays < 0) or after 3am (otherwise).

See also

daysTo() addMonths() addYears() addSecs() Timezone transitions

addMSecs(msecs)
Parameters:

msecs – int

Return type:

QDateTime

Returns a QDateTime object containing a datetime msecs milliseconds later than the datetime of this object (or earlier if msecs is negative).

If this datetime is invalid, an invalid datetime will be returned.

addMonths(months)
Parameters:

months – int

Return type:

QDateTime

Returns a QDateTime object containing a datetime nmonths months later than the datetime of this object (or earlier if nmonths is negative).

If the timeSpec() is LocalTime or TimeZone and the resulting date and time fall in the Standard Time to Daylight-Saving Time transition hour then the result will be just beyond this gap, in the direction of change. If the transition is at 2am and the clock goes forward to 3am, the result of aiming between 2am and 3am will be adjusted to fall before 2am (if nmonths < 0) or after 3am (otherwise).

See also

daysTo() addDays() addYears() addSecs() Timezone transitions

addSecs(secs)
Parameters:

secs – int

Return type:

QDateTime

Returns a QDateTime object containing a datetime s seconds later than the datetime of this object (or earlier if s is negative).

If this datetime is invalid, an invalid datetime will be returned.

addYears(years)
Parameters:

years – int

Return type:

QDateTime

Returns a QDateTime object containing a datetime nyears years later than the datetime of this object (or earlier if nyears is negative).

If the timeSpec() is LocalTime or TimeZone and the resulting date and time fall in the Standard Time to Daylight-Saving Time transition hour then the result will be just beyond this gap, in the direction of change. If the transition is at 2am and the clock goes forward to 3am, the result of aiming between 2am and 3am will be adjusted to fall before 2am (if nyears < 0) or after 3am (otherwise).

See also

daysTo() addDays() addMonths() addSecs() Timezone transitions

static currentDateTime()
Return type:

QDateTime

This is an overloaded function.

static currentDateTime(zone)
Parameters:

zoneQTimeZone

Return type:

QDateTime

Returns the system clock’s current datetime, using the time representation described by zone. If zone is omitted, local time is used.

static currentDateTimeUtc()
Return type:

QDateTime

Returns the system clock’s current datetime, expressed in terms of UTC.

Equivalent to currentDateTime(QTimeZone::UTC).

static currentMSecsSinceEpoch()
Return type:

int

Returns the current number of milliseconds since the start, in UTC, of the year 1970.

This number is like the POSIX time_t variable, but expressed in milliseconds instead of seconds.

static currentSecsSinceEpoch()
Return type:

int

Returns the number of seconds since the start, in UTC, of the year 1970.

This number is like the POSIX time_t variable.

date()
Return type:

QDate

Returns the date part of the datetime.

daysTo(other)
Parameters:

otherQDateTime

Return type:

int

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns the number of days from this datetime to the other datetime. The number of days is counted as the number of times midnight is reached between this datetime to the other datetime. This means that a 10 minute difference from 23:55 to 0:05 the next day counts as one day.

If the other datetime is earlier than this datetime, the value returned is negative.

Example:

startDate = QDateTime(QDate(2012, 7, 6), QTime(8, 30, 0))
endDate = QDateTime(QDate(2012, 7, 7), QTime(16, 30, 0))
print("Days from startDate to endDate: ", startDate.daysTo(endDate))
startDate = QDateTime(QDate(2012, 7, 6), QTime(23, 55, 0))
endDate = QDateTime(QDate(2012, 7, 7), QTime(0, 5, 0))
print("Days from startDate to endDate: ", startDate.daysTo(endDate))
qSwap(startDate, endDate) # Make endDate before startDate.
print("Days from startDate to endDate: ", startDate.daysTo(endDate))
static fromMSecsSinceEpoch(msecs)
Parameters:

msecs – int

Return type:

QDateTime

This is an overloaded function.

static fromMSecsSinceEpoch(msecs, timeZone)
Parameters:
Return type:

QDateTime

Returns a datetime representing a moment the given number msecs of milliseconds after the start, in UTC, of the year 1970, described as specified by timeZone. The default time representation is local time.

Note that there are possible values for msecs that lie outside the valid range of QDateTime , both negative and positive. The behavior of this function is undefined for those values.

static fromMSecsSinceEpoch(msecs, spec[, offsetFromUtc=0])
Parameters:
  • msecs – int

  • specTimeSpec

  • offsetFromUtc – int

Return type:

QDateTime

Note

This function is deprecated.

This is an overloaded function.

Pass a QTimeZone instead, or omit spec and offsetSeconds.

Returns a datetime representing a moment the given number msecs of milliseconds after the start, in UTC, of the year 1970, described as specified by spec and offsetSeconds.

Note that there are possible values for msecs that lie outside the valid range of QDateTime , both negative and positive. The behavior of this function is undefined for those values.

If the spec is not OffsetFromUTC then the offsetSeconds will be ignored. If the spec is OffsetFromUTC and the offsetSeconds is 0 then UTC will be used as the spec, since UTC has zero offset.

If spec is TimeZone then LocalTime will be used in its place, equivalent to using the current system time zone (but differently represented).

static fromSecsSinceEpoch(secs)
Parameters:

secs – int

Return type:

QDateTime

This is an overloaded function.

static fromSecsSinceEpoch(secs, timeZone)
Parameters:
Return type:

QDateTime

Returns a datetime representing a moment the given number secs of seconds after the start, in UTC, of the year 1970, described as specified by timeZone. The default time representation is local time.

Note that there are possible values for secs that lie outside the valid range of QDateTime , both negative and positive. The behavior of this function is undefined for those values.

static fromSecsSinceEpoch(secs, spec[, offsetFromUtc=0])
Parameters:
  • secs – int

  • specTimeSpec

  • offsetFromUtc – int

Return type:

QDateTime

Note

This function is deprecated.

This is an overloaded function.

Pass a QTimeZone instead, or omit spec and offsetSeconds.

Returns a datetime representing a moment the given number secs of seconds after the start, in UTC, of the year 1970, described as specified by spec and offsetSeconds.

Note that there are possible values for secs that lie outside the valid range of QDateTime , both negative and positive. The behavior of this function is undefined for those values.

If the spec is not OffsetFromUTC then the offsetSeconds will be ignored. If the spec is OffsetFromUTC and the offsetSeconds is 0 then UTC will be used as the spec, since UTC has zero offset.

If spec is TimeZone then LocalTime will be used in its place, equivalent to using the current system time zone (but differently represented).

static fromString(string[, format=Qt.TextDate])
Parameters:
Return type:

QDateTime

This is an overloaded function.

static fromString(string[, format=Qt.TextDate])
Parameters:
Return type:

QDateTime

Returns the QDateTime represented by the string, using the format given, or an invalid datetime if this is not possible.

Note for TextDate : only English short month names (e.g. “Jan” in short form or “January” in long form) are recognized.

static fromString(string, format, cal)
Parameters:
  • string – str

  • format – str

  • calQCalendar

Return type:

QDateTime

This is an overloaded function.

static fromString(string, format[, baseYear=QLocale.DefaultTwoDigitBaseYear])
Parameters:
  • string – str

  • format – str

  • baseYear – int

Return type:

QDateTime

This is an overloaded function.

Uses a default-constructed QCalendar .

static fromString(string, format, cal)
Parameters:
  • string – str

  • format – str

  • calQCalendar

Return type:

QDateTime

This is an overloaded function.

static fromString(string, format[, baseYear=QLocale.DefaultTwoDigitBaseYear])
Parameters:
  • string – str

  • format – str

  • baseYear – int

Return type:

QDateTime

This is an overloaded function.

Uses a default-constructed QCalendar .

static fromString(string, format, cal)
Parameters:
  • string – str

  • format – str

  • calQCalendar

Return type:

QDateTime

This is an overloaded function.

static fromString(string, format[, baseYear=QLocale.DefaultTwoDigitBaseYear])
Parameters:
  • string – str

  • format – str

  • baseYear – int

Return type:

QDateTime

This is an overloaded function.

Uses a default-constructed QCalendar .

static fromString(string, format, baseYear, cal)
Parameters:
  • string – str

  • format – str

  • baseYear – int

  • calQCalendar

Return type:

QDateTime

This is an overloaded function.

static fromString(string, format, baseYear, cal)
Parameters:
  • string – str

  • format – str

  • baseYear – int

  • calQCalendar

Return type:

QDateTime

This is an overloaded function.

static fromString(string, format, baseYear, cal)
Parameters:
  • string – str

  • format – str

  • baseYear – int

  • calQCalendar

Return type:

QDateTime

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns the QDateTime represented by the string, using the format given, or an invalid datetime if the string cannot be parsed.

Uses the calendar cal if supplied, else Gregorian.

When format only specifies the last two digits of a year, the 100 years starting at baseYear are the candidates first considered. Prior to 6.7 there was no baseYear parameter and 1900 was always used. This is the default for baseYear, selecting a year from then to 1999. In some cases, other fields may lead to the next or previous century being selected, to get a result consistent with all fields given. See fromString() for details.

In addition to the expressions, recognized in the format string to represent parts of the date and time, by fromString() and fromString() , this method supports:

Expression

Output

t

the timezone (offset, name, “Z” or offset with “UTC” prefix)

tt

the timezone in offset format with no colon between hours and minutes (for example “+0200”)

ttt

the timezone in offset format with a colon between hours and minutes (for example “+02:00”)

tttt

the timezone name (for example “Europe/Berlin”). The name recognized are those known to QTimeZone , which may depend on the operating system in use.

If no ‘t’ format specifier is present, the system’s local time-zone is used. For the defaults of all other fields, see fromString() and fromString() .

For example:

dateTime = QDateTime.fromString("1.30.1", "M.d.s")
# dateTime is January 30 in 1900 at 00:00:01.
dateTime = QDateTime.fromString("12", "yy")
# dateTime is January 1 in 1912 at 00:00:00.

All other input characters will be treated as text. Any non-empty sequence of characters enclosed in single quotes will also be treated (stripped of the quotes) as text and not be interpreted as expressions.

time1 = QTime.fromString("131", "HHh")
# time1 is 13:00:00
time1 = QTime.fromString("1apA", "1amAM")
# time1 is 01:00:00
dateTime2 = QDateTime.fromString("M1d1y9800:01:02",()
                                            "'M'M'd'd'y'yyhh:mm:ss")
# dateTime is 1 January 1998 00:01:02

If the format is not satisfied, an invalid QDateTime is returned. If the format is satisfied but string represents an invalid datetime (e.g. in a gap skipped by a time-zone transition), an valid QDateTime is returned, that represents a near-by datetime that is valid.

The expressions that don’t have leading zeroes (d, M, h, m, s, z) will be greedy. This means that they will use two digits (or three, for z) even if this will put them outside the range and/or leave too few digits for other sections.

dateTime = QDateTime.fromString("130", "Mm") # invalid()

This could have meant 1 January 00:30.00 but the M will grab two digits.

Incorrectly specified fields of the string will cause an invalid QDateTime to be returned. Only datetimes between the local time start of year 100 and end of year 9999 are supported. Note that datetimes near the ends of this range in other time-zones, notably including UTC, may fall outside the range (and thus be treated as invalid) depending on local time zone.

Note

Day and month names as well as AM/PM indicators must be given in English (C locale). If localized month and day names or localized forms of AM/PM are to be recognized, use system() .toDateTime().

Note

If a format character is repeated more times than the longest expression in the table above using it, this part of the format will be read as several expressions with no separator between them; the longest above, possibly repeated as many times as there are copies of it, ending with a residue that may be a shorter expression. Thus 'tttttt' would match "Europe/BerlinEurope/Berlin" and set the zone to Berlin time; if the datetime string contained “Europe/BerlinZ” it would “match” but produce an inconsistent result, leading to an invalid datetime.

isDaylightTime()
Return type:

bool

Returns if this datetime falls in Daylight-Saving Time.

If the TimeSpec is not LocalTime or TimeZone then will always return false.

See also

timeSpec()

isNull()
Return type:

bool

Returns true if both the date and the time are null; otherwise returns false. A null datetime is invalid.

isValid()
Return type:

bool

Returns true if this datetime represents a definite moment, otherwise false.

A datetime is valid if both its date and its time are valid and the time representation used gives a valid meaning to their combination. When the time representation is a specific time-zone or local time, there may be times on some dates that the zone skips in its representation, as when a daylight-saving transition skips an hour (typically during a night in spring). For example, if DST ends at 2am with the clock advancing to 3am, then datetimes from 02:00:00 to 02:59:59.999 on that day are invalid.

msecsTo(other)
Parameters:

otherQDateTime

Return type:

int

Returns the number of milliseconds from this datetime to the other datetime. If the other datetime is earlier than this datetime, the value returned is negative.

Before performing the comparison, the two datetimes are converted to UTC to ensure that the result is correct if daylight-saving (DST) applies to one of the two datetimes and but not the other.

Returns 0 if either datetime is invalid.

offsetFromUtc()
Return type:

int

Returns this datetime’s Offset From UTC in seconds.

The result depends on timeSpec() :

  • Qt::UTC The offset is 0.

  • Qt::OffsetFromUTC The offset is the value originally set.

  • Qt::LocalTime The local time’s offset from UTC is returned.

  • Qt::TimeZone The offset used by the time-zone is returned.

For the last two, the offset at this date and time will be returned, taking account of Daylight-Saving Offset. The offset is the difference between the local time or time in the given time-zone and UTC time; it is positive in time-zones ahead of UTC (East of The Prime Meridian), negative for those behind UTC (West of The Prime Meridian).

__ne__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs is different from rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator==()

__lt__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs is earlier than rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator==()

__le__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs is earlier than or equal to rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator==()

__eq__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs represents the same moment in time as rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator!=() operator operator operator>() operator>=()

__gt__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs is later than rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator==()

__ge__(rhs)
Parameters:

rhsQDateTime

Return type:

bool

Returns true if lhs is later than or equal to rhs; otherwise returns false.

Two datetimes using different time representations can have different offsets from UTC. In this case, they may compare equivalent even if their date() and time() differ, if that difference matches the difference in UTC offset. If their date() and time() coincide, the one with higher offset from UTC is less (earlier) than the one with lower offset. As a result, datetimes are only weakly ordered.

Since 5.14, all invalid datetimes are equivalent and less than all valid datetimes.

See also

operator==()

secsTo(other)
Parameters:

otherQDateTime

Return type:

int

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns the number of seconds from this datetime to the other datetime. If the other datetime is earlier than this datetime, the value returned is negative.

Before performing the comparison, the two datetimes are converted to UTC to ensure that the result is correct if daylight-saving (DST) applies to one of the two datetimes but not the other.

Returns 0 if either datetime is invalid.

Example:

now = QDateTime.currentDateTime()
xmas = QDateTime(QDate(now.date().year(), 12, 25).startOfDay())
qDebug("There are %d seconds to Christmas", now.secsTo(xmas))
setDate(date[, resolve=QDateTime.TransitionResolution.LegacyBehavior])
Parameters:

Sets the date part of this datetime to date.

If no time is set yet, it is set to midnight. If date is invalid, this QDateTime becomes invalid.

If date and time() describe a moment close to a transition for this datetime’s time representation, resolve controls how that situation is resolved.

Note

Prior to Qt 6.7, the version of this function lacked the resolve parameter so had no way to resolve the ambiguities related to transitions.

setMSecsSinceEpoch(msecs)
Parameters:

msecs – int

Sets the datetime to represent a moment a given number, msecs, of milliseconds after the start, in UTC, of the year 1970.

On systems that do not support time zones, this function will behave as if local time were UTC .

Note that passing the minimum of qint64 (std::numeric_limits<qint64>::min()) to msecs will result in undefined behavior.

setOffsetFromUtc(offsetSeconds)
Parameters:

offsetSeconds – int

Note

This function is deprecated.

Use setTimeZone ( fromSecondsAheadOfUtc (offsetSeconds)) instead

Sets the timeSpec() to OffsetFromUTC and the offset to offsetSeconds. The datetime may refer to a different point in time.

The maximum and minimum offset is 14 positive or negative hours. If offsetSeconds is larger or smaller than that, then the result is undefined.

If offsetSeconds is 0 then the timeSpec() will be set to UTC .

setSecsSinceEpoch(secs)
Parameters:

secs – int

Sets the datetime to represent a moment a given number, secs, of seconds after the start, in UTC, of the year 1970.

On systems that do not support time zones, this function will behave as if local time were UTC .

setTime(time[, resolve=QDateTime.TransitionResolution.LegacyBehavior])
Parameters:

Sets the time part of this datetime to time. If time is not valid, this function sets it to midnight. Therefore, it’s possible to clear any set time in a QDateTime by setting it to a default QTime :

QDateTime dt = QDateTime::currentDateTime();
dt.setTime(QTime());

If date() and time describe a moment close to a transition for this datetime’s time representation, resolve controls how that situation is resolved.

Note

Prior to Qt 6.7, the version of this function lacked the resolve parameter so had no way to resolve the ambiguities related to transitions.

setTimeSpec(spec)
Parameters:

specTimeSpec

Note

This function is deprecated.

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Use setTimeZone() instead

Sets the time specification used in this datetime to spec. The datetime may refer to a different point in time.

If spec is OffsetFromUTC then the timeSpec() will be set to UTC , i.e. an effective offset of 0.

If spec is TimeZone then the spec will be set to LocalTime , i.e. the current system time zone.

Example:

local = QDateTime(QDateTime.currentDateTime())
print("Local time is:", local)
UTC = QDateTime(local)
UTC.setTimeSpec(Qt.UTC)
print("UTC time is:", UTC)
print("There are", local.secsTo(UTC), "seconds difference between the datetimes.")
setTimeZone(toZone[, resolve=QDateTime.TransitionResolution.LegacyBehavior])
Parameters:

Sets the time zone used in this datetime to toZone.

The datetime may refer to a different point in time. It uses the time representation of toZone, which may change the meaning of its unchanged date() and time() .

If toZone is invalid then the datetime will be invalid. Otherwise, this datetime’s timeSpec() after the call will match toZone.timeSpec().

If date() and time() describe a moment close to a transition for toZone, resolve controls how that situation is resolved.

Note

Prior to Qt 6.7, the version of this function lacked the resolve parameter so had no way to resolve the ambiguities related to transitions.

swap(other)
Parameters:

otherQDateTime

Swaps this datetime with other. This operation is very fast and never fails.

time()
Return type:

QTime

Returns the time part of the datetime.

timeRepresentation()
Return type:

QTimeZone

Returns a QTimeZone identifying how this datetime represents time.

The timeSpec() of the returned QTimeZone will coincide with that of this datetime; if it is not TimeZone then the returned QTimeZone is a time representation. When their timeSpec() is OffsetFromUTC , the returned QTimeZone ‘s fixedSecondsAheadOfUtc() supplies the offset. When timeSpec() is TimeZone , the QTimeZone object itself is the full representation of that time zone.

timeSpec()
Return type:

TimeSpec

Returns the time specification of the datetime.

This classifies its time representation as local time, UTC, a fixed offset from UTC (without indicating the offset) or a time zone (without giving the details of that time zone). Equivalent to timeRepresentation().timeSpec().

timeZone()
Return type:

QTimeZone

Returns the time zone of the datetime.

The result is the same as timeRepresentation().asBackendZone(). In all cases, the result’s timeSpec() is TimeZone .

When timeSpec() is LocalTime , the result will describe local time at the time this method was called. It will not reflect subsequent changes to the system time zone, even when the QDateTime from which it was obtained does.

timeZoneAbbreviation()
Return type:

str

Returns the Time Zone Abbreviation for this datetime.

The returned string depends on timeSpec() :

Note

The abbreviation is not guaranteed to be unique, i.e. different time zones may have the same abbreviation. For LocalTime and TimeZone , when returned by the host system, the abbreviation may be localized.

toLocalTime()
Return type:

QDateTime

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns a copy of this datetime converted to local time.

The result represents the same moment in time as, and is equal to, this datetime.

Example:

UTC = QDateTime(QDateTime.currentDateTimeUtc())
local = QDateTime(UTC.toLocalTime())
print("UTC time is:", UTC)
print("Local time is:", local)
print("No difference between times:", UTC.secsTo(local))
toMSecsSinceEpoch()
Return type:

int

Returns the datetime as a number of milliseconds after the start, in UTC, of the year 1970.

On systems that do not support time zones, this function will behave as if local time were UTC .

The behavior for this function is undefined if the datetime stored in this object is not valid. However, for all valid dates, this function returns a unique value.

toOffsetFromUtc(offsetSeconds)
Parameters:

offsetSeconds – int

Return type:

QDateTime

Returns a copy of this datetime converted to a spec of OffsetFromUTC with the given offsetSeconds. Equivalent to toTimeZone(QTimeZone::fromSecondsAheadOfUtc(offsetSeconds)).

If the offsetSeconds equals 0 then a UTC datetime will be returned.

The result represents the same moment in time as, and is equal to, this datetime.

toPython()
Return type:

object

toSecsSinceEpoch()
Return type:

int

Returns the datetime as a number of seconds after the start, in UTC, of the year 1970.

On systems that do not support time zones, this function will behave as if local time were UTC .

The behavior for this function is undefined if the datetime stored in this object is not valid. However, for all valid dates, this function returns a unique value.

toString(format)
Parameters:

format – str

Return type:

str

This is an overloaded function.

toString([format=Qt.TextDate])
Parameters:

formatDateFormat

Return type:

str

This is an overloaded function.

Returns the datetime as a string in the format given.

If the format is TextDate , the string is formatted in the default way. The day and month names will be in English. An example of this formatting is “Wed May 20 03:40:13 1998”. For localized formatting, see toString() .

If the format is ISODate , the string format corresponds to the ISO 8601 extended specification for representations of dates and times, taking the form yyyy-MM-ddTHH:mm:ss[Z|±HH:mm], depending on the timeSpec() of the QDateTime . If the timeSpec() is UTC , Z will be appended to the string; if the timeSpec() is OffsetFromUTC , the offset in hours and minutes from UTC will be appended to the string. To include milliseconds in the ISO 8601 date, use the format ISODateWithMs , which corresponds to yyyy-MM-ddTHH:mm:ss.zzz[Z|±HH:mm].

If the format is RFC2822Date , the string is formatted following RFC 2822.

If the datetime is invalid, an empty string will be returned.

Warning

The ISODate format is only valid for years in the range 0 to 9999.

toString(format)
Parameters:

format – str

Return type:

str

This is an overloaded function.

toString(format, cal)
Parameters:
Return type:

str

toString(format, cal)
Parameters:
Return type:

str

toTimeSpec(spec)
Parameters:

specTimeSpec

Return type:

QDateTime

Note

This function is deprecated.

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Use toTimeZone() instead.

Returns a copy of this datetime converted to the given time spec.

The result represents the same moment in time as, and is equal to, this datetime.

If spec is OffsetFromUTC then it is set to UTC . To set to a fixed offset from UTC, use toTimeZone() or toOffsetFromUtc() .

If spec is TimeZone then it is set to LocalTime , i.e. the local Time Zone. To set a specified time-zone, use toTimeZone() .

Example:

local = QDateTime(QDateTime.currentDateTime())
UTC = QDateTime(local.toTimeSpec(Qt.UTC))
print("Local time is:", local)
print("UTC time is:", UTC)
print("No difference between times:", local.secsTo(UTC))
toTimeZone(toZone)
Parameters:

toZoneQTimeZone

Return type:

QDateTime

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns a copy of this datetime converted to the given timeZone.

The result represents the same moment in time as, and is equal to, this datetime.

The result describes the moment in time in terms of timeZone's time representation. For example:

local = QDateTime(QDateTime.currentDateTime())
UTC = QDateTime(local.toTimeSpec(QTimeZone.UTC))
print("Local time is:", local)
print("UTC time is:", UTC)
print("No difference between times represented:", local.secsTo(UTC))

If timeZone is invalid then the datetime will be invalid. Otherwise the returned datetime’s timeSpec() will match timeZone.timeSpec().

toUTC()
Return type:

QDateTime

Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Returns a copy of this datetime converted to UTC.

The result represents the same moment in time as, and is equal to, this datetime.

Example:

local = QDateTime(QDateTime.currentDateTime())
UTC = QDateTime(local.toUTC())
print("Local time is:", local)
print("UTC time is:", UTC)
print("No difference between times:", local.secsTo(UTC))