{"id":20563,"date":"2018-05-10T10:40:35","date_gmt":"2018-05-10T14:40:35","guid":{"rendered":"https:\/\/www.bloomberg.com\/company\/stories\/work-dates-time-python\/"},"modified":"2022-11-14T15:42:29","modified_gmt":"2022-11-14T20:42:29","slug":"work-dates-time-python","status":"publish","type":"post","link":"https:\/\/www.bloomberg.com\/company\/stories\/work-dates-time-python\/","title":{"rendered":"How to work with dates and time with Python"},"content":{"rendered":"
\n \n\t\n\t\n\t
\n\t\t\n\t\t\t
\n\t
\n \n

Get a better understanding of datetime in Python with this primer by Senior Software Developer Mario Corchero.<\/em><\/p>\n

This article was originally\u00a0published on Opensource.com<\/a>\u00a0<\/span>under the\u00a0<\/span>CC BY-SA 4.0<\/a>\u00a0<\/span>license. It has been updated by the author in preparation for the forthcoming release of Python 3.7.<\/em><\/p>\n\n<\/div>\n

\n\t
\n<\/div>\n
\n \n

\"How<\/p>\n

Image by: Matteo Ianeselli<\/a>. Modified by Opensource.com. CC-BY-3.0<\/a>.<\/h6>\n\n<\/div>\n
\n \n

When trying to make things work with the datetime module, most Python users have faced a point when we resort to guess-and-check until the errors go away. datetime is one of those APIs that seems easy to use, but requires the developer to have a deep understanding of what a few things actually mean. Otherwise, given the complexity of date- and time-related issues, introducing unexpected bugs is easy.<\/p>\n

Time standards<\/h2>\n

The first concept to grasp when working with time is a standard that defines how we can measure units of time. The same way we have standards to measure weight or length that define kilograms or meters, we need an accurate way to define what a ‘second’<\/em> means. We can then use other time references\u2014such as days, weeks, or years\u2014using a calendar standard as multiples of the second (see Gregorian Calendar<\/a> as an example).<\/p>\n

UT1<\/h3>\n

One of the simplest ways to measure a second is as a fraction of the day, given that we can reliably guarantee the sun will rise and set every day (in most places). This gave birth to Universal Time (UT1), the successor of GMT (Greenwich Mean Time). Today, we use stars and quasars to measure how long it takes for the Earth to perform a full rotation around the sun. Even if this seems precise enough, it still has issues; due to the gravitational pull of the moon, tides, and earthquakes, the days change length all year long. Although this is not a problem for most applications, it becomes a non-trivial problem when we require really precise measurements. GPS triangulation is a good example of a time-sensitive process, in which being a second off results in a completely different location on the globe.<\/p>\n

TAI<\/h3>\n

As a result, the International Atomic Time (TAI<\/a>) was designed to be as precise as possible. Using atomic clocks<\/a> in multiple laboratories across the earth, we get the most accurate and constant measure of the second, which allows us to compute time intervals with the highest accuracy. This precision is both a blessing and a curse as TAI is so exact that it deviates from UT1 (or what we call civil time)<\/i>. This means that we will eventually have our clock noon deviate substantially from the solar noon.<\/p>\n

UTC<\/h3>\n

That led to the development of Coordinated Universal Time (UTC<\/a>), which brought together the best of the both units. UTC uses the measurement of a second as defined by TAI. This allows for accurate measurement of time while introducing leap seconds to ensure that the time does not deviate from UT1 by more than 0.9 seconds.<\/p>\n

How all this plays together on your computer<\/h3>\n

With all this background, you should now be able to understand how the operating system is serving time at any given moment. While the computer doesn’t have an atomic clock inside but uses an internal clock synchronized with the rest of the world via Network Time Protocol (NTP<\/a>).<\/p>\n

In Unix-like systems, the most common way to measure time is by using POSIX time<\/a>, which is defined as the number of seconds that have elapsed the Unix epoch (Thursday, January 1, 1970), without taking leap seconds into account. As POSIX time does not handle leap seconds (nor does Python), some companies have defined their own way of handling time by smearing the leap second across the time around it through their NTP servers (see Google time<\/a> as an example).<\/p>\n

Time zones<\/h2>\n

\"Time<\/p>\n

I’ve explained what UTC is and how it allows us to define dates and times, but countries like to have their wall time noon match with the solar time for noon, so the sun is at the top of the sky at 12 PM. That is why UTC defines offsets, so we can have 12 AM with an offset of +4 hours from UTC. This effectively means that the actual time without offset is 8 AM.<\/p>\n

Governments define the standard offset from UTC that a geographical position follows, effectively creating a time zone. The most common database for time zones is known as the Olson Database<\/a>. This can be retrieved in Python using dateutil.tz<\/b><\/a>:<\/p>\n

>><\/span>><\/span> from<\/span> dateutil.<\/span>tz import<\/span> gettz\r\n>><\/span>><\/span> gettz(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>\r\n<\/pre>\n
The result of gettz<\/strong> gives us an object that we can use to create time-zone-aware dates in Python:<\/p>\n
>><\/span>><\/span> import<\/span> datetime as<\/span> dt\r\n>><\/span>><\/span> dt.<\/span>datetime.<\/span>now(<\/span>)<\/span>.<\/span>isoformat(<\/span>)<\/span>\r\n'2017-04-15T14:16:56.551778'<\/span>  # This is a naive datetime<\/span>\r\n>><\/span>><\/span> dt.<\/span>datetime.<\/span>now(<\/span>gettz(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>)<\/span>.<\/span>isoformat(<\/span>)<\/span>\r\n'2017-04-15T14:17:01.256587+02:00'<\/span>  # This is a tz aware datetime, always prefer these<\/span>\r\n<\/pre>\n
Should we want to use just plain UTC in Python 3, we don’t need any external libraries:<\/p>\n
>><\/span>><\/span> dt.<\/span>datetime.<\/span>now(<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>.<\/span>isoformat(<\/span>)<\/span>\r\n'2017-04-15T12:22:06.637355+00:00'<\/span>\r\n<\/pre>\n
DST<\/h2>\n
Once we grasp all this knowledge, we might feel prepared to work with time zones, but we must be aware of one more thing that happens in some time zones: Daylight Saving Time (DST).<\/p>\n
The countries that follow DST will move their clocks one hour forward in spring, and one hour backward in autumn to return to the standard time of the time zone. This effectively implies that a single time zone can have multiple offsets, as we can see in the following example:<\/p>\n
>><\/span>><\/span> dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 7<\/span>,<\/span> 1<\/span>,<\/span> tzinfo=<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>.<\/span>astimezone(<\/span>gettz(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>)<\/span>\r\n'2017-07-01T02:00:00+02:00'<\/span>\r\n>><\/span>><\/span> dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 1<\/span>,<\/span> 1<\/span>,<\/span> tzinfo=<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>.<\/span>astimezone(<\/span>gettz(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>)<\/span>\r\n'2017-01-01T01:00:00+01:00'<\/span>\r\n<\/pre>\n
This gives us days that are made of 23 or 25 hours, resulting in really interesting time arithmetic. Depending on the time and the time zone, adding a day does not necessarily mean adding 24 hours:<\/p>\n
>><\/span>><\/span> today =<\/span> dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 10<\/span>,<\/span> 29<\/span>,<\/span> tzinfo=<\/span>gettz(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> tomorrow =<\/span> today +<\/span> dt.<\/span>timedelta(<\/span>days=<\/span>1<\/span>)<\/span>\r\n>><\/span>><\/span> tomorrow.<\/span>astimezone(<\/span>dt.<\/span>timezone.<\/span>utc)<\/span> -<\/span> today.<\/span>astimezone(<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>\r\ndatetime.<\/span>timedelta(<\/span>1<\/span>,<\/span> 3600<\/span>)<\/span>  # We've added 25 hours<\/span>\r\n<\/pre>\n
When working with timestamps, the best strategy is to use non DST-aware time zones (ideally UTC+00:00).<\/p>\n
Serializing your datetime objects<\/h2>\n
The day will come that you need to send your datetime objects in JSON<\/a> and you will get the following:<\/p>\n
>>><\/span> now =<\/span> dt.datetime<\/span>.now<\/span>(<\/span>dt.timezone<\/span>.utc<\/span>)<\/span>\r\n>>><\/span> json.dumps<\/span>(<\/span>now)<\/span>\r\nTypeError<\/span>: Object of type<\/span> 'datetime'<\/span> is<\/span> not<\/span> JSON serializable<\/pre>\n
There are three main ways to serialize datetime in JSON:<\/p>\n
String<\/h3>\n
datetime has two main functions to convert to and from a string given a specific format: strftime<\/strong> and strptime<\/b><\/a>. The best way is to use the standard ISO_8601<\/a> for serializing time-related objects as string, which is done by calling isoformat<\/b> on the datetime object:<\/p>\n
>><\/span>><\/span> now =<\/span> dt.<\/span>datetime.<\/span>now(<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>\r\n>><\/span>><\/span> json.<\/span>dumps(<\/span>now)<\/span>\r\nTypeError<\/span>:<\/span> Object<\/span> of type<\/span> 'datetime'<\/span> is<\/span> not<\/span> JSON serializable\r\n<\/pre>\n
To get a datetime object from a string that was formatted using isoformat<\/b> with a UTC time zone, we can rely on strptime<\/b>:<\/p>\n
>><\/span>><\/span> dt.<\/span>datetime.<\/span>strptime(<\/span>now_str,<\/span> \"%Y-%m-%dT%H:%M:%S.%f+00:00\"<\/span>)<\/span>.<\/span>replace(<\/span>tzinfo=<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 19<\/span>,<\/span> 21<\/span>,<\/span> 49<\/span>,<\/span> 5<\/span>,<\/span> 542320<\/span>,<\/span> tzinfo=<\/span>datetime.<\/span>timezone.<\/span>utc)<\/span>\r\n<\/pre>\n
In this example, we are hard-coding the offset to be UTC and then setting it once the datetime object has been created. A better way to fully parse the string including the offset is by using the external library dateutil:<\/b><\/p>\n
>><\/span>><\/span> from<\/span> dateutil.<\/span>parser import<\/span> parse\r\n>><\/span>><\/span> parse(<\/span>'2017-04-19T21:49:05.542320+00:00'<\/span>)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 19<\/span>,<\/span> 21<\/span>,<\/span> 49<\/span>,<\/span> 5<\/span>,<\/span> 542320<\/span>,<\/span> tzinfo=<\/span>tzutc(<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> parse(<\/span>'2017-04-19T21:49:05.542320+01:00'<\/span>)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 19<\/span>,<\/span> 21<\/span>,<\/span> 49<\/span>,<\/span> 5<\/span>,<\/span> 542320<\/span>,<\/span> tzinfo=<\/span>tzoffset(<\/span>None<\/span>,<\/span> 3600<\/span>)<\/span>)<\/span>\r\n<\/pre>\n
Note, once we serialize and de-serialize, we lose the time zone information and keep only the offset.<\/p>\n
In Python 3.7, a new function ‘fromisoformat’ will been added to datetime that will allow developers to parse datetimes from strings produced out of ‘isoformat.’<\/p>\n
Integer<\/h3>\n
We are able to store a datetime as an integer by using the number of seconds that passed since a specific epoch (reference date). As I mentioned earlier, the most-known epoch in computer systems is the Unix epoch, which references the first second since 1970. This means that 5<\/b> represents the fifth second on January 1, 1970.<\/p>\n
The Python standard library provides us with tools to get the current time as Unix time and to transform between datetime objects and their int<\/b> representations as Unix time.<\/p>\n
Getting the current time as an integer:<\/p>\n
>><\/span>><\/span> import<\/span> datetime as<\/span> dt\r\n>><\/span>><\/span> from<\/span> dateutil.<\/span>tz import<\/span> gettz\r\n>><\/span>><\/span> import<\/span> time\r\n>><\/span>><\/span> unix_time =<\/span> time.<\/span>time(<\/span>)<\/span>\r\n<\/pre>\n
Unix time to datetime:<\/p>\n
>><\/span>><\/span> unix_time\r\n1492636231.597816<\/span>\r\n>><\/span>><\/span> datetime =<\/span> dt.<\/span>datetime.<\/span>fromtimestamp(<\/span>unix_time,<\/span> gettz(<\/span>\"Europe\/London\"<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> datetime.<\/span>isoformat(<\/span>)<\/span>\r\n'2017-04-19T22:10:31.597816+01:00'<\/span>\r\n<\/pre>\n
Getting the Unix time given a datetime:<\/p>\n
>><\/span>><\/span> time.<\/span>mktime(<\/span>datetime.<\/span>timetuple(<\/span>)<\/span>)<\/span>\r\n1492636231.0<\/span>\r\n>><\/span>><\/span> # or using the calendar library<\/span>\r\n>><\/span>><\/span> calendar.<\/span>timegm(<\/span>datetime.<\/span>timetuple(<\/span>)<\/span>)<\/span>\r\n<\/pre>\n
Objects<\/h3>\n
The last option is to serialize the object itself as an object that will give special meaning at decoding time:<\/p>\n
import<\/span> datetime as<\/span> dt\r\nfrom<\/span> dateutil.<\/span>tz import<\/span> gettz,<\/span> tzoffset\r\n\r\ndef<\/span> json_to_dt(<\/span>obj)<\/span>:<\/span>\r\n    if<\/span> obj.<\/span>pop(<\/span>'__type__'<\/span>,<\/span> None<\/span>)<\/span> !=<\/span> \"datetime\"<\/span>:<\/span>\r\n        return<\/span> obj\r\n    zone,<\/span> offset =<\/span> obj.<\/span>pop(<\/span>\"tz\"<\/span>)<\/span>\r\n    obj[<\/span>\"tzinfo\"<\/span>]<\/span> =<\/span> tzoffset(<\/span>zone,<\/span> offset)<\/span>\r\n    return<\/span> dt.<\/span>datetime(<\/span>**<\/span>obj)<\/span>\r\n\r\ndef<\/span> dt_to_json(<\/span>obj)<\/span>:<\/span>\r\n    if<\/span> isinstance<\/span>(<\/span>obj,<\/span> dt.<\/span>datetime)<\/span>:<\/span>\r\n        return<\/span> {<\/span>\r\n            \"__type__\"<\/span>:<\/span> \"datetime\"<\/span>,<\/span>\r\n            \"year\"<\/span>:<\/span> obj.<\/span>year,<\/span>\r\n            \"month\"<\/span> :<\/span> obj.<\/span>month,<\/span>\r\n            \"day\"<\/span> :<\/span> obj.<\/span>day,<\/span>\r\n            \"hour\"<\/span> :<\/span> obj.<\/span>hour,<\/span>\r\n            \"minute\"<\/span> :<\/span> obj.<\/span>minute,<\/span>\r\n            \"second\"<\/span> :<\/span> obj.<\/span>second,<\/span>\r\n            \"microsecond\"<\/span> :<\/span> obj.<\/span>microsecond,<\/span>\r\n            \"tz\"<\/span>:<\/span> (<\/span>obj.<\/span>tzinfo.<\/span>tzname(<\/span>obj)<\/span>,<\/span> obj.<\/span>utcoffset(<\/span>)<\/span>.<\/span>total_seconds(<\/span>)<\/span>)<\/span>\r\n        }<\/span>\r\n    else<\/span>:<\/span>\r\n        raise<\/span> TypeError<\/span>(<\/span>\"Cant serialize {}\"<\/span>.<\/span>format(<\/span>obj)<\/span>)<\/span>\r\n<\/pre>\n
Now we can encode JSON:<\/p>\n
>><\/span>><\/span> import<\/span> json\r\n>><\/span>><\/span> now =<\/span> dt.<\/span>datetime.<\/span>now(<\/span>dt.<\/span>timezone.<\/span>utc)<\/span>\r\n>><\/span>><\/span> json.<\/span>dumps(<\/span>now,<\/span> default=<\/span>dt_to_json)<\/span>  # From datetime<\/span>\r\n'{\"__type__\": \"datetime\", \"year\": 2017, \"month\": 4, \"day\": 19, \"hour\": 22, \"minute\": 32, \"second\": 44, \"microsecond\": 778735, \"tz\": \"UTC\"}'<\/span>\r\n>><\/span>><\/span> # Also works with timezones<\/span>\r\n>><\/span>><\/span> now =<\/span> dt.<\/span>datetime.<\/span>now(<\/span>gettz(<\/span>\"Europe\/London\"<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> json.<\/span>dumps(<\/span>now,<\/span> default=<\/span>dt_to_json)<\/span>\r\n'{\"__type__\": \"datetime\", \"year\": 2017, \"month\": 4, \"day\": 19, \"hour\": 23, \"minute\": 33, \"second\": 46, \"microsecond\": 681533, \"tz\": \"BST\"}'<\/span>\r\n<\/pre>\n
And decode:<\/p>\n
>><\/span>><\/span> input_json=<\/span>'{\"__type__\": \"datetime\", \"year\": 2017, \"month\": 4, \"day\": 19, \"hour\": 23, \"minute\": 33, \"second\": 46, \"microsecond\": 681533, \"tz\": \"BST\"}'<\/span>\r\n>><\/span>><\/span> json.<\/span>loads(<\/span>input_json,<\/span> object_hook=<\/span>json_to_dt)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 19<\/span>,<\/span> 23<\/span>,<\/span> 33<\/span>,<\/span> 46<\/span>,<\/span> 681533<\/span>,<\/span> tzinfo=<\/span>tzlocal(<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> input_json=<\/span>'{\"__type__\": \"datetime\", \"year\": 2017, \"month\": 4, \"day\": 19, \"hour\": 23, \"minute\": 33, \"second\": 46, \"microsecond\": 681533, \"tz\": \"EST\"}'<\/span>\r\n>><\/span>><\/span> json.<\/span>loads(<\/span>input_json,<\/span> object_hook=<\/span>json_to_dt)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 19<\/span>,<\/span> 23<\/span>,<\/span> 33<\/span>,<\/span> 46<\/span>,<\/span> 681533<\/span>,<\/span> tzinfo=<\/span>tzfile(<\/span>'\/usr\/share\/zoneinfo\/EST'<\/span>)<\/span>)<\/span>\r\n>><\/span>><\/span> json.<\/span>loads(<\/span>input_json,<\/span> object_hook=<\/span>json_to_dt)<\/span>.<\/span>isoformat(<\/span>)<\/span>\r\n'2017-04-19T23:33:46.681533-05:00'<\/span>\r\n<\/pre>\n
Wall times<\/h2>\n
After this, you might be tempted to convert all datetime objects to UTC and work only with UTC datetimes and fixed offsets. Even if this is by far the best approach for timestamps, it quickly breaks for future wall times.<\/p>\n
We can distinguish two main types of time<\/i> points: wall times and timestamps. Timestamps are universal points in time not related to anywhere in particular. Examples include the time a star is born or when a line is logged to a file. Things change when we speak about the time “we read on the wall clock.” When we say “see you tomorrow at 2,” we are not referring to UTC offsets, but to tomorrow at 2 PM in our local time zone, no matter what the offset is at this point. We cannot just map those wall times to timestamps (although we can for past ones) because, for future occurrences, countries might change their offset, which happens more frequently than you might think.<\/p>\n
For those situations, we need to save the datetime with the time zone to which it refers, and not the offset.<\/p>\n
Differences when working with pytz<\/h2>\n
Since Python 3.6, the recommended library to get the Olson database is dateutil.tz<\/a><\/b>, but it used to be pytz<\/a><\/b>.<\/p>\n
They might seem similar, but, in some situations, their approaches to handling time zones is quite different. Getting the current time is simple as well:<\/p>\n
>><\/span>><\/span> import<\/span> pytz\r\n>><\/span>><\/span> dt.<\/span>datetime.<\/span>now(<\/span>pytz.<\/span>timezone(<\/span>\"Europe\/London\"<\/span>)<\/span>)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 4<\/span>,<\/span> 20<\/span>,<\/span> 0<\/span>,<\/span> 13<\/span>,<\/span> 26<\/span>,<\/span> 469264<\/span>,<\/span> tzinfo=<\/span><<\/span>DstTzInfo 'Europe\/London'<\/span> BST+<\/span>1<\/span>:<\/span>00<\/span>:<\/span>00<\/span> DST><\/span>)<\/span>\r\n<\/pre>\n
A common pitfall with pytz<\/b> it to pass a pytz<\/b> time zone as a tzinfo<\/b> attribute of a datetime:<\/p>\n
>><\/span>><\/span> dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 5<\/span>,<\/span> 1<\/span>,<\/span> tzinfo=<\/span>pytz.<\/span>timezone(<\/span>\"Europe\/Helsinki\"<\/span>)<\/span>)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 5<\/span>,<\/span> 1<\/span>,<\/span> 0<\/span>,<\/span> 0<\/span>,<\/span> tzinfo=<\/span><<\/span>DstTzInfo 'Europe\/Helsinki'<\/span> LMT+<\/span>1<\/span>:<\/span>40<\/span>:<\/span>00<\/span> STD><\/span>)<\/span>\r\n>><\/span>><\/span> pytz.<\/span>timezone(<\/span>\"Europe\/Helsinki\"<\/span>)<\/span>.<\/span>localize(<\/span>dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 5<\/span>,<\/span> 1<\/span>)<\/span>,<\/span> is_dst=<\/span>None<\/span>)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 5<\/span>,<\/span> 1<\/span>,<\/span> 0<\/span>,<\/span> tzinfo=<\/span><<\/span>DstTzInfo 'Europe\/Helsinki'<\/span> EEST+<\/span>3<\/span>:<\/span>00<\/span>:<\/span>00<\/span> DST><\/span>)<\/span>\r\n<\/pre>\n
We always should call localize<\/b> on the datetime objects we build. Otherwise, pytz<\/b> will assign the first offset it finds for the time zone.<\/p>\n
Another major difference can be found when performing time arithmetic. While we saw that the additions worked in dateutil<\/b> as if we were adding wall time in the specified time zone, when the datetime has a pytz<\/b> tzinfo<\/b> instance, absolute hours are added and the caller must call normalize<\/b> after the operation, as it won’t handle DST changes. For example:<\/p>\n
>><\/span>><\/span> today =<\/span> dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 10<\/span>,<\/span> 29<\/span>)<\/span>\r\n>><\/span>><\/span> tz =<\/span> pytz.<\/span>timezone(<\/span>\"Europe\/Madrid\"<\/span>)<\/span>\r\n>><\/span>><\/span> today =<\/span> tz.<\/span>localize(<\/span>dt.<\/span>datetime(<\/span>2017<\/span>,<\/span> 10<\/span>,<\/span> 29<\/span>)<\/span>,<\/span> is_dst=<\/span>None<\/span>)<\/span>\r\n>><\/span>><\/span> tomorrow =<\/span> today +<\/span> dt.<\/span>timedelta(<\/span>days=<\/span>1<\/span>)<\/span>\r\n>><\/span>><\/span> tomorrow\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 10<\/span>,<\/span> 30<\/span>,<\/span> 0<\/span>,<\/span> 0<\/span>,<\/span> tzinfo=<\/span><<\/span>DstTzInfo 'Europe\/Madrid'<\/span> CEST+<\/span>2<\/span>:<\/span>00<\/span>:<\/span>00<\/span> DST><\/span>)<\/span>\r\n>><\/span>><\/span> tz.<\/span>normalize(<\/span>tomorrow)<\/span>\r\ndatetime.<\/span>datetime(<\/span>2017<\/span>,<\/span> 10<\/span>,<\/span> 29<\/span>,<\/span> 23<\/span>,<\/span> 0<\/span>,<\/span> tzinfo=<\/span><<\/span>DstTzInfo 'Europe\/Madrid'<\/span> CET+<\/span>1<\/span>:<\/span>00<\/span>:<\/span>00<\/span> STD><\/span>)<\/span>\r\n<\/pre>\n
Note that with the pytz tzinfo<\/b>, it has added 24 absolute hours (23 hours on the wall time).<\/p>\n
The following table shows the way to get either wall\/timestamps arithmetic with both pytz<\/b> and dateutil<\/b>:<\/p>\n\n<\/div>\n
\n    \n    \n\n\n\n\n\n\n\n
<\/td>\npytz<\/strong><\/td>\n<\/tr>\n
wall time<\/td>\nobj.tzinfo.localize(obj.replace(tzinfo=None) + timedelta, is_dst=is_dst)<\/td>\n<\/tr>\n
absolute time<\/td>\nobj.tzinfo.normalize(obj + timedelta)<\/td>\n<\/tr>\n
<\/td>\ndateutil<\/strong><\/td>\n<\/tr>\n
wall time<\/td>\nobj + timedelta<\/td>\n<\/tr>\n
absolute time<\/td>\n(obj.astimezone(pytz.utc) + timedelta).astimezone(obj.tzinfo)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n<\/div>\n
\n    \n    
Note that adding wall times can lead to unexpected results when DST changes occur.<\/p>\n
Finally, dateutil<\/b> plays nicely with the fold attribute added in PEP0495<\/a> and provides backward compatibility if you are using earlier versions of Python.<\/p>\n
Quick tips<\/h2>\n
After all this, how should we avoid the common issues when working with time?<\/p>\n
We can see how to get the current time via the now<\/a><\/b> function of datetime. On the second call we pass a tzinfo<\/a><\/b> object which sets the time zone and displays the offset in the ISO string representation<\/a> of that datetime.<\/p>\n