1. UTC offsets
Sometimes, you really need to know exactly when something happened. Up until now, the datetime objects you have worked with are what is called "naive", and can't be compared across different parts of the world. They don't know anything about their time zone.
2. Time zones
Why does this matter? Before time zones, each town or city set its clock so that noon was directly overhead.
3. Time zones
Another city 100 miles away would also set their clocks to be noon when the sun was overhead.
4. Time zones
But this meant that these two cities had clocks that were different, by maybe 15 or 20 minutes. When people moved by foot or horseback, this wasn't a problem.
5. Time zones
Then railroads, and later telegraphs, came into existence. Now you could move or communicate with someone 100 or even 1000 miles away fast enough that time had to be consistent.
6. Time zones
Governments solved this problem by declaring that all clocks within a wide area would agree on the hour, even if some were ahead or behind of their solar time. The United States, for example, has 4 major time zones, plus one for Alaska and another for Hawaii.
Our bike data was collected in Washington, DC, which observes Eastern time.
7. UTC
But since we're not using the sun anymore, how do we know how to set the clock? Because the United Kingdom was the first to standardize its time, everyone in the world sets their clocks relative to the original historical UK standard.
This standard time is called UTC. Because all clocks are set relative to UTC, we can compare time around the world.
Generally, clocks west of the UK are set earlier than UTC, and clocks east of the UK are set later than UTC.
For example, the eastern United States is typically UTC minus 5 hours, while India is typically UTC plus 5 hours 30 minutes.
8. UTC
Let's see this in code.
As before, you import datetime and timedelta. Now you also import timezone. This will let you specify what timezone the clock was in when our data was recorded.
9. UTC
We create a timezone object, which accepts a timedelta that explains how to translate your datetime into UTC. In this case, since the clock that measured our bicycle data set was five hours behind UTC, we create ET to be at UTC-5.
We can specify what time zone the clock was in when the last ride started in our data set. The clock that recorded the ride was 5 hours behind UTC.
Now if you print it, your datetime includes the UTC offset.
10. UTC
Making a datetime "aware" of its timezone means you can ask Python new questions.
For example, suppose you want to know what the date and time would have been if the clock had been set to India Standard Time instead. First, create a new timezone object set to UTC plus 5 hours 30 minutes.
Now use the astimezone() method to ask Python to create a new datetime object corresponding to the same moment, but adjusted to a different time zone.
In this case, because clocks in India would have been set 10-point-5 hours ahead of clocks on the eastern US, the last ride would have taken place on December 31, at 1 hour, 39 minutes, and 3 seconds past midnight local time. Same moment, different clock.
11. Adjusting timezone vs changing tzinfo
Finally, there is an important difference between adjusting timezones and changing the tzinfo directly.
You can set the tzinfo directly, using the replace() method. Here we've set the tzinfo to be timezone-dot-utc, a convenient object with zero UTC offset. The clock stays the same, but the UTC offset has shifted.
Or, just like before, you can call the astimezone() method. Now if we adjust into UTC with astimezone(timezone-dot-utc), we change both the UTC offset and the clock itself.
12. UTC Offsets
Now that you have learned about UTC offsets, which allow us to compare times around the world, it's time to practice using them!