With sufficient knowledge of applicable algorithmic and political time
adjustments, such as time zone and daylight saving time information,
an aware object can locate itself relative to other aware objects.
An aware object represents a specific moment in time that is not open to
interpretation. 1

A naive object does not contain enough information to unambiguously locate
itself relative to other date/time objects. Whether a naive object represents
Coordinated Universal Time (UTC), local time, or time in some other timezone is
purely up to the program, just like it is up to the program whether a
particular number represents metres, miles, or mass. Naive objects are easy to
understand and to work with, at the cost of ignoring some aspects of reality.

For applications requiring aware objects, datetime and time
objects have an optional time zone information attribute, tzinfo, that
can be set to an instance of a subclass of the abstract tzinfo class.
These tzinfo objects capture information about the offset from UTC
time, the time zone name, and whether daylight saving time is in effect.

Only one concrete tzinfo class, the timezone class, is
supplied by the datetime module. The timezone class can
represent simple timezones with fixed offsets from UTC, such as UTC itself or
North American EST and EDT timezones. Supporting timezones at deeper levels of
detail is up to the application. The rules for time adjustment across the
world are more political than rational, change frequently, and there is no
standard suitable for every application aside from UTC.

An idealized naive date, assuming the current Gregorian calendar always was, and
always will be, in effect. Attributes: year, month, and
day.

class datetime.time

An idealized time, independent of any particular day, assuming that every day
has exactly 24*60*60 seconds. (There is no notion of “leap seconds” here.)
Attributes: hour, minute, second, microsecond,
and tzinfo.

A duration expressing the difference between two date, time,
or datetime instances to microsecond resolution.

class datetime.tzinfo

An abstract base class for time zone information objects. These are used by the
datetime and time classes to provide a customizable notion of
time adjustment (for example, to account for time zone and/or daylight saving
time).

class datetime.timezone

A class that implements the tzinfo abstract base class as a
fixed offset from the UTC.

If any argument is a float and there are fractional microseconds,
the fractional microseconds left over from all arguments are
combined and their sum is rounded to the nearest microsecond using
round-half-to-even tiebreaker. If no argument is a float, the
conversion and normalization processes are exact (no information is
lost).

If the normalized value of days lies outside the indicated range,
OverflowError is raised.

Note that normalization of negative values may be surprising at first. For
example:

The expression t2-t3 will always be equal to the expression t2+(-t3) except
when t3 is equal to timedelta.max; in that case the former will produce a result
while the latter will overflow.

In addition to the operations listed above, timedelta objects support
certain additions and subtractions with date and datetime
objects (see below).

Changed in version 3.2: Floor division and true division of a timedelta object by another
timedelta object are now supported, as are remainder operations and
the divmod() function. True division and multiplication of a
timedelta object by a float object are now supported.

Return the total number of seconds contained in the duration. Equivalent to
td/timedelta(seconds=1). For interval units other than seconds, use the
division form directly (e.g. td/timedelta(microseconds=1)).

Note that for very large time intervals (greater than 270 years on
most platforms) this method will lose microsecond accuracy.

Return the local date corresponding to the POSIX timestamp, such as is
returned by time.time().

This may raise OverflowError, if the timestamp is out
of the range of values supported by the platform C localtime()
function, and OSError on localtime() failure.
It’s common for this to be restricted to years from 1970 through 2038. Note
that on non-POSIX systems that include leap seconds in their notion of a
timestamp, leap seconds are ignored by fromtimestamp().

Changed in version 3.3: Raise OverflowError instead of ValueError if the timestamp
is out of the range of values supported by the platform C
localtime() function. Raise OSError instead of
ValueError on localtime() failure.

Between 1 and the number of days in the given month of the given year.

Supported operations:

Operation

Result

date2=date1+timedelta

date2 is timedelta.days days removed
from date1. (1)

date2=date1-timedelta

Computes date2 such that date2+timedelta==date1. (2)

timedelta=date1-date2

(3)

date1<date2

date1 is considered less than date2 when
date1 precedes date2 in time. (4)

Notes:

date2 is moved forward in time if timedelta.days>0, or backward if
timedelta.days<0. Afterward date2-date1==timedelta.days.
timedelta.seconds and timedelta.microseconds are ignored.
OverflowError is raised if date2.year would be smaller than
MINYEAR or larger than MAXYEAR.

timedelta.seconds and timedelta.microseconds are ignored.

This is exact, and cannot overflow. timedelta.seconds and
timedelta.microseconds are 0, and date2 + timedelta == date1 after.

In other words, date1<date2 if and only if date1.toordinal()<date2.toordinal(). Date comparison raises TypeError if
the other comparand isn’t also a date object. However,
NotImplemented is returned instead if the other comparand has a
timetuple() attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a date
object is compared to an object of a different type, TypeError is raised
unless the comparison is == or !=. The latter cases return
False or True, respectively.

The ISO calendar is a widely used variant of the Gregorian calendar. 3

The ISO year consists of 52 or 53 full weeks, and where a week starts on a
Monday and ends on a Sunday. The first week of an ISO year is the first
(Gregorian) calendar week of a year containing a Thursday. This is called week
number 1, and the ISO year of that Thursday is the same as its Gregorian year.

For example, 2004 begins on a Thursday, so the first week of ISO year 2004
begins on Monday, 29 Dec 2003 and ends on Sunday, 4 Jan 2004:

Return a string representing the date, controlled by an explicit format string.
Format codes referring to hours, minutes or seconds will see 0 values. For a
complete list of formatting directives, see
strftime() and strptime() Behavior.

If optional argument tz is None
or not specified, this is like today(), but, if possible, supplies more
precision than can be gotten from going through a time.time() timestamp
(for example, this may be possible on platforms supplying the C
gettimeofday() function).

If tz is not None, it must be an instance of a tzinfo subclass,
and the current date and time are converted to tz’s time zone.

This is like now(), but returns the current UTC date and time, as a naive
datetime object. An aware current UTC datetime can be obtained by
calling datetime.now(timezone.utc). See also now().

Warning

Because naive datetime objects are treated by many datetime methods
as local times, it is preferred to use aware datetimes to represent times
in UTC. As such, the recommended way to create an object representing the
current time in UTC by calling datetime.now(timezone.utc).

Return the local date and time corresponding to the POSIX timestamp, such as is
returned by time.time(). If optional argument tz is None or not
specified, the timestamp is converted to the platform’s local date and time, and
the returned datetime object is naive.

If tz is not None, it must be an instance of a tzinfo subclass, and the
timestamp is converted to tz’s time zone.

fromtimestamp() may raise OverflowError, if the timestamp is out of
the range of values supported by the platform C localtime() or
gmtime() functions, and OSError on localtime() or
gmtime() failure.
It’s common for this to be restricted to years in
1970 through 2038. Note that on non-POSIX systems that include leap seconds in
their notion of a timestamp, leap seconds are ignored by fromtimestamp(),
and then it’s possible to have two timestamps differing by a second that yield
identical datetime objects. This method is preferred over
utcfromtimestamp().

Changed in version 3.3: Raise OverflowError instead of ValueError if the timestamp
is out of the range of values supported by the platform C
localtime() or gmtime() functions. Raise OSError
instead of ValueError on localtime() or gmtime()
failure.

Return the UTC datetime corresponding to the POSIX timestamp, with
tzinfoNone. (The resulting object is naive.)

This may raise OverflowError, if the timestamp is
out of the range of values supported by the platform C gmtime() function,
and OSError on gmtime() failure.
It’s common for this to be restricted to years in 1970 through 2038.

On the POSIX compliant platforms, it is equivalent to the following
expression:

datetime(1970,1,1,tzinfo=timezone.utc)+timedelta(seconds=timestamp)

except the latter formula always supports the full years range: between
MINYEAR and MAXYEAR inclusive.

Warning

Because naive datetime objects are treated by many datetime methods
as local times, it is preferred to use aware datetimes to represent times
in UTC. As such, the recommended way to create an object representing a
specific timestamp in UTC by calling
datetime.fromtimestamp(timestamp,tz=timezone.utc).

Changed in version 3.3: Raise OverflowError instead of ValueError if the timestamp
is out of the range of values supported by the platform C
gmtime() function. Raise OSError instead of
ValueError on gmtime() failure.

Return the datetime corresponding to the proleptic Gregorian ordinal,
where January 1 of year 1 has ordinal 1. ValueError is raised unless 1<=ordinal<=datetime.max.toordinal(). The hour, minute, second and
microsecond of the result are all 0, and tzinfo is None.

Return a new datetime object whose date components are equal to the
given date object’s, and whose time components
are equal to the given time object’s. If the tzinfo
argument is provided, its value is used to set the tzinfo attribute
of the result, otherwise the tzinfo attribute of the time argument
is used.

For any datetime object d,
d==datetime.combine(d.date(),d.time(),d.tzinfo). If date is a
datetime object, its time components and tzinfo attributes
are ignored.

This does not support parsing arbitrary ISO 8601 strings - it is only intended
as the inverse operation of datetime.isoformat(). A more full-featured
ISO 8601 parser, dateutil.parser.isoparse is available in the third-party package
dateutil.
This does not support parsing arbitrary ISO 8601 strings - it is only intended
as the inverse operation of datetime.isoformat().

Return a datetime corresponding to the ISO calendar date specified
by year, week and day. The non-date components of the datetime are populated
with their normal default values. This is the inverse of the function
datetime.isocalendar().

In [0,1]. Used to disambiguate wall times during a repeated interval. (A
repeated interval occurs when clocks are rolled back at the end of daylight saving
time or when the UTC offset for the current zone is decreased for political reasons.)
The value 0 (1) represents the earlier (later) of the two moments with the same wall
time representation.

datetime2 is a duration of timedelta removed from datetime1, moving forward in
time if timedelta.days > 0, or backward if timedelta.days < 0. The
result has the same tzinfo attribute as the input datetime, and
datetime2 - datetime1 == timedelta after. OverflowError is raised if
datetime2.year would be smaller than MINYEAR or larger than
MAXYEAR. Note that no time zone adjustments are done even if the
input is an aware object.

Computes the datetime2 such that datetime2 + timedelta == datetime1. As for
addition, the result has the same tzinfo attribute as the input
datetime, and no time zone adjustments are done even if the input is aware.

Subtraction of a datetime from a datetime is defined only if
both operands are naive, or if both are aware. If one is aware and the other is
naive, TypeError is raised.

If both are naive, or both are aware and have the same tzinfo attribute,
the tzinfo attributes are ignored, and the result is a timedelta
object t such that datetime2+t==datetime1. No time zone adjustments
are done in this case.

If both are aware and have different tzinfo attributes, a-b acts
as if a and b were first converted to naive UTC datetimes first. The
result is (a.replace(tzinfo=None)-a.utcoffset())-(b.replace(tzinfo=None)-b.utcoffset()) except that the implementation never overflows.

datetime1 is considered less than datetime2 when datetime1 precedes
datetime2 in time.

If one comparand is naive and the other is aware, TypeError
is raised if an order comparison is attempted. For equality
comparisons, naive instances are never equal to aware instances.

If both comparands are aware, and have the same tzinfo attribute, the
common tzinfo attribute is ignored and the base datetimes are
compared. If both comparands are aware and have different tzinfo
attributes, the comparands are first adjusted by subtracting their UTC
offsets (obtained from self.utcoffset()).

In order to stop comparison from falling back to the default scheme of comparing
object addresses, datetime comparison normally raises TypeError if the
other comparand isn’t also a datetime object. However,
NotImplemented is returned instead if the other comparand has a
timetuple() attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a datetime
object is compared to an object of a different type, TypeError is raised
unless the comparison is == or !=. The latter cases return
False or True, respectively.

Return a datetime with the same attributes, except for those attributes given
new values by whichever keyword arguments are specified. Note that
tzinfo=None can be specified to create a naive datetime from an aware
datetime with no conversion of date and time data.

Return a datetime object with new tzinfo attribute tz,
adjusting the date and time data so the result is the same UTC time as
self, but in tz’s local time.

If provided, tz must be an instance of a tzinfo subclass, and its
utcoffset() and dst() methods must not return None. If self
is naive, it is presumed to represent time in the system timezone.

If called without arguments (or with tz=None) the system local
timezone is assumed for the target timezone. The .tzinfo attribute of the converted
datetime instance will be set to an instance of timezone
with the zone name and offset obtained from the OS.

If self.tzinfo is tz, self.astimezone(tz) is equal to self: no
adjustment of date or time data is performed. Else the result is local
time in the timezone tz, representing the same UTC time as self: after
astz=dt.astimezone(tz), astz-astz.utcoffset() will have
the same date and time data as dt-dt.utcoffset().

If you merely want to attach a time zone object tz to a datetime dt without
adjustment of date and time data, use dt.replace(tzinfo=tz). If you
merely want to remove the time zone object from an aware datetime dt without
conversion of date and time data, use dt.replace(tzinfo=None).

defastimezone(self,tz):ifself.tzinfoistz:returnself# Convert self to UTC, and attach the new time zone object.utc=(self-self.utcoffset()).replace(tzinfo=tz)# Convert from UTC to tz's local time.returntz.fromutc(utc)

Changed in version 3.3: tz now can be omitted.

Changed in version 3.6: The astimezone() method can now be called on naive instances that
are presumed to represent system local time.

where yday=d.toordinal()-date(d.year,1,1).toordinal()+1
is the day number within the current year starting with 1 for January
1st. The tm_isdst flag of the result is set according to the
dst() method: tzinfo is None or dst() returns
None, tm_isdst is set to -1; else if dst() returns a
non-zero value, tm_isdst is set to 1; else tm_isdst is
set to 0.

If datetime instance d is naive, this is the same as
d.timetuple() except that tm_isdst is forced to 0 regardless of what
d.dst() returns. DST is never in effect for a UTC time.

If d is aware, d is normalized to UTC time, by subtracting
d.utcoffset(), and a time.struct_time for the
normalized time is returned. tm_isdst is forced to 0. Note
that an OverflowError may be raised if d.year was
MINYEAR or MAXYEAR and UTC adjustment spills over a year
boundary.

Warning

Because naive datetime objects are treated by many datetime methods
as local times, it is preferred to use aware datetimes to represent times
in UTC; as a result, using utcfromtimetuple may give misleading
results. If you have a naive datetime representing UTC, use
datetime.replace(tzinfo=timezone.utc) to make it aware, at which point
you can use datetime.timetuple().

Return POSIX timestamp corresponding to the datetime
instance. The return value is a float similar to that
returned by time.time().

Naive datetime instances are assumed to represent local
time and this method relies on the platform C mktime()
function to perform the conversion. Since datetime
supports wider range of values than mktime() on many
platforms, this method may raise OverflowError for times far
in the past or far in the future.

Changed in version 3.6: The timestamp() method uses the fold attribute to
disambiguate the times during a repeated interval.

Note

There is no method to obtain the POSIX timestamp directly from a
naive datetime instance representing UTC time. If your
application uses this convention and your system timezone is not
set to UTC, you can obtain the POSIX timestamp by supplying
tzinfo=timezone.utc:

The example below defines a tzinfo subclass capturing time zone
information for Kabul, Afghanistan, which used +4 UTC until 1945
and then +4:30 UTC thereafter:

fromdatetimeimporttimedelta,datetime,tzinfo,timezoneclassKabulTz(tzinfo):# Kabul used +4 until 1945, when they moved to +4:30UTC_MOVE_DATE=datetime(1944,12,31,20,tzinfo=timezone.utc)defutcoffset(self,dt):ifdt.year<1945:returntimedelta(hours=4)elif(1945,1,1,0,0)<=dt.timetuple()[:5]<(1945,1,1,0,30):# An ambiguous ("imaginary") half-hour range representing# a 'fold' in time due to the shift from +4 to +4:30.# If dt falls in the imaginary range, use fold to decide how# to resolve. See PEP495.returntimedelta(hours=4,minutes=(30ifdt.foldelse0))else:returntimedelta(hours=4,minutes=30)deffromutc(self,dt):# Follow same validations as in datetime.tzinfoifnotisinstance(dt,datetime):raiseTypeError("fromutc() requires a datetime argument")ifdt.tzinfoisnotself:raiseValueError("dt.tzinfo is not self")# A custom implementation is required for fromutc as# the input to this function is a datetime with utc values# but with a tzinfo set to self.# See datetime.astimezone or fromtimestamp.ifdt.replace(tzinfo=timezone.utc)>=self.UTC_MOVE_DATE:returndt+timedelta(hours=4,minutes=30)else:returndt+timedelta(hours=4)defdst(self,dt):# Kabul does not observe daylight saving time.returntimedelta(0)deftzname(self,dt):ifdt>=self.UTC_MOVE_DATE:return"+04:30"return"+04"

In [0,1]. Used to disambiguate wall times during a repeated interval. (A
repeated interval occurs when clocks are rolled back at the end of daylight saving
time or when the UTC offset for the current zone is decreased for political reasons.)
The value 0 (1) represents the earlier (later) of the two moments with the same wall
time representation.

New in version 3.6.

time objects support comparison of time to time,
where a is considered less
than b when a precedes b in time. If one comparand is naive and the other
is aware, TypeError is raised if an order comparison is attempted. For equality
comparisons, naive instances are never equal to aware instances.

If both comparands are aware, and have
the same tzinfo attribute, the common tzinfo attribute is
ignored and the base times are compared. If both comparands are aware and
have different tzinfo attributes, the comparands are first adjusted by
subtracting their UTC offsets (obtained from self.utcoffset()). In order
to stop mixed-type comparisons from falling back to the default comparison by
object address, when a time object is compared to an object of a
different type, TypeError is raised unless the comparison is == or
!=. The latter cases return False or True, respectively.

Changed in version 3.3: Equality comparisons between aware and naive time instances
don’t raise TypeError.

Changed in version 3.5: Before Python 3.5, a time object was considered to be false if it
represented midnight in UTC. This behavior was considered obscure and
error-prone and has been removed in Python 3.5. See bpo-13936 for full
details.

Return a time with the same value, except for those attributes given
new values by whichever keyword arguments are specified. Note that
tzinfo=None can be specified to create a naive time from an
aware time, without conversion of the time data.

This is an abstract base class, meaning that this class should not be
instantiated directly. Define a subclass of tzinfo to capture
information about a particular time zone.

An instance of (a concrete subclass of) tzinfo can be passed to the
constructors for datetime and time objects. The latter objects
view their attributes as being in local time, and the tzinfo object
supports methods revealing offset of local time from UTC, the name of the time
zone, and DST offset, all relative to a date or time object passed to them.

You need to derive a concrete subclass, and (at least)
supply implementations of the standard tzinfo methods needed by the
datetime methods you use. The datetime module provides
timezone, a simple concrete subclass of tzinfo which can
represent timezones with fixed offset from UTC such as UTC itself or North
American EST and EDT.

Special requirement for pickling: A tzinfo subclass must have an
__init__() method that can be called with no arguments, otherwise it can be
pickled but possibly not unpickled again. This is a technical requirement that
may be relaxed in the future.

A concrete subclass of tzinfo may need to implement the following
methods. Exactly which methods are needed depends on the uses made of aware
datetime objects. If in doubt, simply implement all of them.

Return offset of local time from UTC, as a timedelta object that is
positive east of UTC. If local time is west of UTC, this should be negative.

This represents the total offset from UTC; for example, if a
tzinfo object represents both time zone and DST adjustments,
utcoffset() should return their sum. If the UTC offset isn’t known,
return None. Else the value returned must be a timedelta object
strictly between -timedelta(hours=24) and timedelta(hours=24)
(the magnitude of the offset must be less than one day). Most implementations
of utcoffset() will probably look like one of these two:

Return the daylight saving time (DST) adjustment, as a timedelta
object or
None if DST information isn’t known.

Return timedelta(0) if DST is not in effect.
If DST is in effect, return the offset as a timedelta object
(see utcoffset() for details). Note that DST offset, if applicable, has
already been added to the UTC offset returned by utcoffset(), so there’s
no need to consult dst() unless you’re interested in obtaining DST info
separately. For example, datetime.timetuple() calls its tzinfo
attribute’s dst() method to determine how the tm_isdst flag
should be set, and tzinfo.fromutc() calls dst() to account for
DST changes when crossing time zones.

An instance tz of a tzinfo subclass that models both standard and
daylight times must be consistent in this sense:

tz.utcoffset(dt)-tz.dst(dt)

must return the same result for every datetimedt with dt.tzinfo==tz For sane tzinfo subclasses, this expression yields the time
zone’s “standard offset”, which should not depend on the date or the time, but
only on geographic location. The implementation of datetime.astimezone()
relies on this, but cannot detect violations; it’s the programmer’s
responsibility to ensure it. If a tzinfo subclass cannot guarantee
this, it may be able to override the default implementation of
tzinfo.fromutc() to work correctly with astimezone() regardless.

Most implementations of dst() will probably look like one of these two:

defdst(self,dt):# Code to set dston and dstoff to the time zone's DST# transition times based on the input dt.year, and expressed# in standard local time.ifdston<=dt.replace(tzinfo=None)<dstoff:returntimedelta(hours=1)else:returntimedelta(0)

Return the time zone name corresponding to the datetime object dt, as
a string. Nothing about string names is defined by the datetime module,
and there’s no requirement that it mean anything in particular. For example,
“GMT”, “UTC”, “-500”, “-5:00”, “EDT”, “US/Eastern”, “America/New York” are all
valid replies. Return None if a string name isn’t known. Note that this is
a method rather than a fixed string primarily because some tzinfo
subclasses will wish to return different names depending on the specific value
of dt passed, especially if the tzinfo class is accounting for
daylight time.

These methods are called by a datetime or time object, in
response to their methods of the same names. A datetime object passes
itself as the argument, and a time object passes None as the
argument. A tzinfo subclass’s methods should therefore be prepared to
accept a dt argument of None, or of class datetime.

When None is passed, it’s up to the class designer to decide the best
response. For example, returning None is appropriate if the class wishes to
say that time objects don’t participate in the tzinfo protocols. It
may be more useful for utcoffset(None) to return the standard UTC offset, as
there is no other convention for discovering the standard offset.

When a datetime object is passed in response to a datetime
method, dt.tzinfo is the same object as self. tzinfo methods can
rely on this, unless user code calls tzinfo methods directly. The
intent is that the tzinfo methods interpret dt as being in local
time, and not need worry about objects in other timezones.

This is called from the default datetime.astimezone()
implementation. When called from that, dt.tzinfo is self, and dt’s
date and time data are to be viewed as expressing a UTC time. The purpose
of fromutc() is to adjust the date and time data, returning an
equivalent datetime in self’s local time.

Most tzinfo subclasses should be able to inherit the default
fromutc() implementation without problems. It’s strong enough to handle
fixed-offset time zones, and time zones accounting for both standard and
daylight time, and the latter even if the DST transition times differ in
different years. An example of a time zone the default fromutc()
implementation may not handle correctly in all cases is one where the standard
offset (from UTC) depends on the specific date and time passed, which can happen
for political reasons. The default implementations of astimezone() and
fromutc() may not produce the result you want if the result is one of the
hours straddling the moment the standard offset changes.

deffromutc(self,dt):# raise ValueError error if dt.tzinfo is not selfdtoff=dt.utcoffset()dtdst=dt.dst()# raise ValueError if dtoff is None or dtdst is Nonedelta=dtoff-dtdst# this is self's standard offsetifdelta:dt+=delta# convert to standard local timedtdst=dt.dst()# raise ValueError if dtdst is Noneifdtdst:returndt+dtdstelse:returndt

fromdatetimeimporttzinfo,timedelta,datetimeZERO=timedelta(0)HOUR=timedelta(hours=1)SECOND=timedelta(seconds=1)# A class capturing the platform's idea of local time.# (May result in wrong values on historical times in# timezones where UTC offset and/or the DST rules had# changed in the past.)importtimeas_timeSTDOFFSET=timedelta(seconds=-_time.timezone)if_time.daylight:DSTOFFSET=timedelta(seconds=-_time.altzone)else:DSTOFFSET=STDOFFSETDSTDIFF=DSTOFFSET-STDOFFSETclassLocalTimezone(tzinfo):deffromutc(self,dt):assertdt.tzinfoisselfstamp=(dt-datetime(1970,1,1,tzinfo=self))//SECONDargs=_time.localtime(stamp)[:6]dst_diff=DSTDIFF//SECOND# Detect foldfold=(args==_time.localtime(stamp-dst_diff))returndatetime(*args,microsecond=dt.microsecond,tzinfo=self,fold=fold)defutcoffset(self,dt):ifself._isdst(dt):returnDSTOFFSETelse:returnSTDOFFSETdefdst(self,dt):ifself._isdst(dt):returnDSTDIFFelse:returnZEROdeftzname(self,dt):return_time.tzname[self._isdst(dt)]def_isdst(self,dt):tt=(dt.year,dt.month,dt.day,dt.hour,dt.minute,dt.second,dt.weekday(),0,0)stamp=_time.mktime(tt)tt=_time.localtime(stamp)returntt.tm_isdst>0Local=LocalTimezone()# A complete implementation of current DST rules for major US time zones.deffirst_sunday_on_or_after(dt):days_to_go=6-dt.weekday()ifdays_to_go:dt+=timedelta(days_to_go)returndt# US DST Rules## This is a simplified (i.e., wrong for a few cases) set of rules for US# DST start and end times. For a complete and up-to-date set of DST rules# and timezone definitions, visit the Olson Database (or try pytz):# http://www.twinsun.com/tz/tz-link.htm# http://sourceforge.net/projects/pytz/ (might not be up-to-date)## In the US, since 2007, DST starts at 2am (standard time) on the second# Sunday in March, which is the first Sunday on or after Mar 8.DSTSTART_2007=datetime(1,3,8,2)# and ends at 2am (DST time) on the first Sunday of Nov.DSTEND_2007=datetime(1,11,1,2)# From 1987 to 2006, DST used to start at 2am (standard time) on the first# Sunday in April and to end at 2am (DST time) on the last# Sunday of October, which is the first Sunday on or after Oct 25.DSTSTART_1987_2006=datetime(1,4,1,2)DSTEND_1987_2006=datetime(1,10,25,2)# From 1967 to 1986, DST used to start at 2am (standard time) on the last# Sunday in April (the one on or after April 24) and to end at 2am (DST time)# on the last Sunday of October, which is the first Sunday# on or after Oct 25.DSTSTART_1967_1986=datetime(1,4,24,2)DSTEND_1967_1986=DSTEND_1987_2006defus_dst_range(year):# Find start and end times for US DST. For years before 1967, return# start = end for no DST.if2006<year:dststart,dstend=DSTSTART_2007,DSTEND_2007elif1986<year<2007:dststart,dstend=DSTSTART_1987_2006,DSTEND_1987_2006elif1966<year<1987:dststart,dstend=DSTSTART_1967_1986,DSTEND_1967_1986else:return(datetime(year,1,1),)*2start=first_sunday_on_or_after(dststart.replace(year=year))end=first_sunday_on_or_after(dstend.replace(year=year))returnstart,endclassUSTimeZone(tzinfo):def__init__(self,hours,reprname,stdname,dstname):self.stdoffset=timedelta(hours=hours)self.reprname=reprnameself.stdname=stdnameself.dstname=dstnamedef__repr__(self):returnself.reprnamedeftzname(self,dt):ifself.dst(dt):returnself.dstnameelse:returnself.stdnamedefutcoffset(self,dt):returnself.stdoffset+self.dst(dt)defdst(self,dt):ifdtisNoneordt.tzinfoisNone:# An exception may be sensible here, in one or both cases.# It depends on how you want to treat them. The default# fromutc() implementation (called by the default astimezone()# implementation) passes a datetime with dt.tzinfo is self.returnZEROassertdt.tzinfoisselfstart,end=us_dst_range(dt.year)# Can't compare naive to aware objects, so strip the timezone from# dt first.dt=dt.replace(tzinfo=None)ifstart+HOUR<=dt<end-HOUR:# DST is in effect.returnHOURifend-HOUR<=dt<end:# Fold (an ambiguous hour): use dt.fold to disambiguate.returnZEROifdt.foldelseHOURifstart<=dt<start+HOUR:# Gap (a non-existent hour): reverse the fold rule.returnHOURifdt.foldelseZERO# DST is off.returnZEROdeffromutc(self,dt):assertdt.tzinfoisselfstart,end=us_dst_range(dt.year)start=start.replace(tzinfo=self)end=end.replace(tzinfo=self)std_time=dt+self.stdoffsetdst_time=std_time+HOURifend<=dst_time<end+HOUR:# Repeated hourreturnstd_time.replace(fold=1)ifstd_time<startordst_time>=end:# Standard timereturnstd_timeifstart<=std_time<end-HOUR:# Daylight saving timereturndst_timeEastern=USTimeZone(-5,"Eastern","EST","EDT")Central=USTimeZone(-6,"Central","CST","CDT")Mountain=USTimeZone(-7,"Mountain","MST","MDT")Pacific=USTimeZone(-8,"Pacific","PST","PDT")

Note that there are unavoidable subtleties twice per year in a tzinfo
subclass accounting for both standard and daylight time, at the DST transition
points. For concreteness, consider US Eastern (UTC -0500), where EDT begins the
minute after 1:59 (EST) on the second Sunday in March, and ends the minute after
1:59 (EDT) on the first Sunday in November:

When DST starts (the “start” line), the local wall clock leaps from 1:59 to
3:00. A wall time of the form 2:MM doesn’t really make sense on that day, so
astimezone(Eastern) won’t deliver a result with hour==2 on the day DST
begins. For example, at the Spring forward transition of 2016, we get:

When DST ends (the “end” line), there’s a potentially worse problem: there’s an
hour that can’t be spelled unambiguously in local wall time: the last hour of
daylight time. In Eastern, that’s times of the form 5:MM UTC on the day
daylight time ends. The local wall clock leaps from 1:59 (daylight time) back
to 1:00 (standard time) again. Local times of the form 1:MM are ambiguous.
astimezone() mimics the local clock’s behavior by mapping two adjacent UTC
hours into the same local hour then. In the Eastern example, UTC times of the
form 5:MM and 6:MM both map to 1:MM when converted to Eastern, but earlier times
have the fold attribute set to 0 and the later times have it set to 1.
For example, at the Fall back transition of 2016, we get:

Note that the datetime instances that differ only by the value of the
fold attribute are considered equal in comparisons.

Applications that can’t bear wall-time ambiguities should explicitly check the
value of the fold attribute or avoid using hybrid
tzinfo subclasses; there are no ambiguities when using timezone,
or any other fixed-offset tzinfo subclass (such as a class representing
only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).

The Time Zone Database (often called tz, tzdata or zoneinfo) contains code
and data that represent the history of local time for many representative
locations around the globe. It is updated periodically to reflect changes
made by political bodies to time zone boundaries, UTC offsets, and
daylight-saving rules.

The timezone class is a subclass of tzinfo, each
instance of which represents a timezone defined by a fixed offset from
UTC.

Objects of this class cannot be used to represent timezone information in the
locations where different offsets are used in different days of the year or
where historical changes have been made to civil time.

The offset argument must be specified as a timedelta
object representing the difference between the local time and UTC. It must
be strictly between -timedelta(hours=24) and
timedelta(hours=24), otherwise ValueError is raised.

The name argument is optional. If specified it must be a string that
will be used as the value returned by the datetime.tzname() method.

New in version 3.2.

Changed in version 3.7: The UTC offset is not restricted to a whole number of minutes.

Return the fixed value specified when the timezone instance
is constructed.

If name is not provided in the constructor, the name returned by
tzname(dt) is generated from the value of the offset as follows. If
offset is timedelta(0), the name is “UTC”, otherwise it is a string in
the format UTC±HH:MM, where ± is the sign of offset, HH and MM are
two digits of offset.hours and offset.minutes respectively.

Changed in version 3.6: Name generated from offset=timedelta(0) is now plain ‘UTC’, not
'UTC+00:00'.

The following is a list of all the format codes that the 1989 C standard
requires, and these work on all platforms with a standard C implementation.

Directive

Meaning

Example

Notes

%a

Weekday as locale’s
abbreviated name.

Sun, Mon, …, Sat
(en_US);

So, Mo, …, Sa
(de_DE)

(1)

%A

Weekday as locale’s full name.

Sunday, Monday, …,
Saturday (en_US);

Sonntag, Montag, …,
Samstag (de_DE)

(1)

%w

Weekday as a decimal number,
where 0 is Sunday and 6 is
Saturday.

0, 1, …, 6

%d

Day of the month as a
zero-padded decimal number.

01, 02, …, 31

(9)

%b

Month as locale’s abbreviated
name.

Jan, Feb, …, Dec
(en_US);

Jan, Feb, …, Dez
(de_DE)

(1)

%B

Month as locale’s full name.

January, February,
…, December (en_US);

Januar, Februar, …,
Dezember (de_DE)

(1)

%m

Month as a zero-padded
decimal number.

01, 02, …, 12

(9)

%y

Year without century as a
zero-padded decimal number.

00, 01, …, 99

(9)

%Y

Year with century as a decimal
number.

0001, 0002, …, 2013,
2014, …, 9998, 9999

(2)

%H

Hour (24-hour clock) as a
zero-padded decimal number.

00, 01, …, 23

(9)

%I

Hour (12-hour clock) as a
zero-padded decimal number.

01, 02, …, 12

(9)

%p

Locale’s equivalent of either
AM or PM.

AM, PM (en_US);

am, pm (de_DE)

(1),
(3)

%M

Minute as a zero-padded
decimal number.

00, 01, …, 59

(9)

%S

Second as a zero-padded
decimal number.

00, 01, …, 59

(4),
(9)

%f

Microsecond as a decimal
number, zero-padded on the
left.

000000, 000001, …,
999999

(5)

%z

UTC offset in the form
±HHMM[SS[.ffffff]] (empty
string if the object is
naive).

(empty), +0000,
-0400, +1030,
+063415,
-030712.345216

(6)

%Z

Time zone name (empty string
if the object is naive).

(empty), UTC, EST, CST

%j

Day of the year as a
zero-padded decimal number.

001, 002, …, 366

(9)

%U

Week number of the year
(Sunday as the first day of
the week) as a zero padded
decimal number. All days in a
new year preceding the first
Sunday are considered to be in
week 0.

00, 01, …, 53

(7),
(9)

%W

Week number of the year
(Monday as the first day of
the week) as a decimal number.
All days in a new year
preceding the first Monday
are considered to be in
week 0.

00, 01, …, 53

(7),
(9)

%c

Locale’s appropriate date and
time representation.

Tue Aug 16 21:30:00
1988 (en_US);

Di 16 Aug 21:30:00
1988 (de_DE)

(1)

%x

Locale’s appropriate date
representation.

08/16/88 (None);

08/16/1988 (en_US);

16.08.1988 (de_DE)

(1)

%X

Locale’s appropriate time
representation.

21:30:00 (en_US);

21:30:00 (de_DE)

(1)

%%

A literal '%' character.

%

Several additional directives not required by the C89 standard are included for
convenience. These parameters all correspond to ISO 8601 date values.

Directive

Meaning

Example

Notes

%G

ISO 8601 year with century
representing the year that
contains the greater part of
the ISO week (%V).

0001, 0002, …, 2013,
2014, …, 9998, 9999

(8)

%u

ISO 8601 weekday as a decimal
number where 1 is Monday.

1, 2, …, 7

%V

ISO 8601 week as a decimal
number with Monday as
the first day of the week.
Week 01 is the week containing
Jan 4.

01, 02, …, 53

(8),
(9)

These may not be available on all platforms when used with the strftime()
method. The ISO 8601 year and ISO 8601 week directives are not interchangeable
with the year and week number directives above. Calling strptime() with
incomplete or ambiguous ISO 8601 directives will raise a ValueError.

The full set of format codes supported varies across platforms, because Python
calls the platform C library’s strftime() function, and platform
variations are common. To see the full set of format codes supported on your
platform, consult the strftime(3) documentation.

Broadly speaking, d.strftime(fmt) acts like the time module’s
time.strftime(fmt,d.timetuple()) although not all objects support a
timetuple() method.

For the datetime.strptime() class method, the default value is
1900-01-01T00:00:00.000: any components not specified in the format string
will be pulled from the default value. 4

Using datetime.strptime(date_string,format) is equivalent to:

datetime(*(time.strptime(date_string,format)[0:6]))

except when the format includes sub-second components or timezone offset
information, which are supported in datetime.strptime but are discarded by
time.strptime.

For time objects, the format codes for year, month, and day should not
be used, as time objects have no such values. If they’re used anyway,
1900 is substituted for the year, and 1 for the month and day.

For date objects, the format codes for hours, minutes, seconds, and
microseconds should not be used, as date objects have no such
values. If they’re used anyway, 0 is substituted for them.

For the same reason, handling of format strings containing Unicode code points
that can’t be represented in the charset of the current locale is also
platform-dependent. On some platforms such code points are preserved intact in
the output, while on others strftime may raise UnicodeError or return
an empty string instead.

Notes:

Because the format depends on the current locale, care should be taken when
making assumptions about the output value. Field orderings will vary (for
example, “month/day/year” versus “day/month/year”), and the output may
contain Unicode characters encoded using the locale’s default encoding (for
example, if the current locale is ja_JP, the default encoding could be
any one of eucJP, SJIS, or utf-8; use locale.getlocale()
to determine the current locale’s encoding).

The strptime() method can parse years in the full [1, 9999] range, but
years < 1000 must be zero-filled to 4-digit width.

Changed in version 3.2: In previous versions, strftime() method was restricted to
years >= 1900.

Changed in version 3.3: In version 3.2, strftime() method was restricted to
years >= 1000.

When used with the strptime() method, the %p directive only affects
the output hour field if the %I directive is used to parse the hour.

Unlike the time module, the datetime module does not support
leap seconds.

When used with the strptime() method, the %f directive
accepts from one to six digits and zero pads on the right. %f is
an extension to the set of format characters in the C standard (but
implemented separately in datetime objects, and therefore always
available).

For a naive object, the %z and %Z format codes are replaced by empty
strings.

For an aware object:

%z

utcoffset() is transformed into a string of the form
±HHMM[SS[.ffffff]], where HH is a 2-digit string giving the number
of UTC offset hours, MM is a 2-digit string giving the number of UTC
offset minutes, SS is a 2-digit string giving the number of UTC offset
seconds and ffffff is a 6-digit string giving the number of UTC
offset microseconds. The ffffff part is omitted when the offset is a
whole number of seconds and both the ffffff and the SS part is
omitted when the offset is a whole number of minutes. For example, if
utcoffset() returns timedelta(hours=-3,minutes=-30), %z is
replaced with the string '-0330'.

Changed in version 3.7: The UTC offset is not restricted to a whole number of minutes.

Changed in version 3.7: When the %z directive is provided to the strptime() method,
the UTC offsets can have a colon as a separator between hours, minutes
and seconds.
For example, '+01:00:00' will be parsed as an offset of one hour.
In addition, providing 'Z' is identical to '+00:00'.

%Z

If tzname() returns None, %Z is replaced by an empty
string. Otherwise %Z is replaced by the returned value, which must
be a string.

Changed in version 3.2: When the %z directive is provided to the strptime() method, an
aware datetime object will be produced. The tzinfo of the
result will be set to a timezone instance.

When used with the strptime() method, %U and %W are only used
in calculations when the day of the week and the calendar year (%Y)
are specified.

Similar to %U and %W, %V is only used in calculations when the
day of the week and the ISO year (%G) are specified in a
strptime() format string. Also note that %G and %Y are not
interchangeable.

When used with the strptime() method, the leading zero is optional
for formats %d, %m, %H, %I, %M, %S, %J, %U,
%W, and %V. Format %y does require a leading zero.

This matches the definition of the “proleptic Gregorian” calendar in
Dershowitz and Reingold’s book Calendrical Calculations,
where it’s the base calendar for all computations. See the book for
algorithms for converting between proleptic Gregorian ordinals and
many other calendar systems.