To make time zones better we're gonna be using library named pytz.

We've already installed it for you on Workspaces, but

you'll need to install it yourself locally.

You can do this with pip install pytz.

All right, let's see how this tool works.

All right, we're going to need our date time libraries.

So we have all that imported.

And we're also gonna be using pytz as we talked about.

So we have that imported as well.

All right, so pytz I really recommend you go look at the docs for

it, it has a whole lot of stuff that makes all this work so much easier.

So, in our last video, we did Eastern and Pacific by specifying time deltas.

Well, let's do those again.

We'll do Pacific first and [SOUND] we're gonna do the pytz method.

And so we actually specify the name of the time zone.

So, for instance, we want the US Pacific time zone,

we specify US Pacific and if we do Eastern, [SOUND] US Eastern.

Okay.

So now we have those, great.

Now let's use let's give ourselves this format string.

We're gonna use this a lot so we're just gonna go ahead and put this in here.

So, this should be familiar.

[BLANK_AUDIO]

All right so, year, month, day, hour, minute, second, and

then we're gonna do cap Z and lowercase z, and so what do these two do?

Well cap Z gives us the time zone name so Pacific or

India standard time or whatever.

And the lowercase z prints out the offset of that timezone from UTC.

So we'd get like minus 8, or plus 550, or, or whatever.

Speaking of UTC, let's make a variable that holds onto UTC.

You can actually just do pytz.utc.

We're only saving five characters, but, you know, I get lazy as a programmer.

So let's make a date time in the Pacific time zone,

with the one that we've been doing, all right?

Pacific.localize, datetime.datetime,

2014, 4, 21, 9.

[BLANK_AUDIO]

So what's the pacific.localize?

Well what that does is it takes a naive date time or

it can work with aware ones too, I do believe.

But anyway, it takes a date time and gives it to you with a certain time zone.

So if we do start.strftime with our format string, then there we go.

We've got Pacific daylight time at 7 hours ahead.

And we've got our date and our time.

'Kay, so that's awesome.

We can see from our usual info here that it's in the Pacific time zone, and let's,

let's do what we did before and let's try turning this into an Eastern time zone.

So let's call this start_eastern.

[SOUND] And we're gonna go back to using that as time zone.

So now if I look at start_eastern, I get this new one and we can see that it is,

[SOUND] well let's look at start.

So we can see these two here, right?

So we've got PDT and EDT.

And we've got our correct times.

So that's great.

But why did we use this as time zone instead of using localize again?

Well, localize is for naive date times.

And since our start variable was already time zone aware, it's no longer naive.

We can't localize it again.

Most of the time, though, you're gonna wanna work with times in UTC.

And you're gonna convert them when they get put out, right,

when they go out to a local time.

So, let's see about how we would do that.

So, let's do a start utc,

datetime.datetime, [SOUND] 2014,

4, 21, 1 and tz is gonna be utc.

So now, if I start_utc and put in my format string, then, we get that, right?

UTC is plus 0, that's exactly where we wanna be.

Okay. So now,

let's convert this back to Pacific.

So start utc.astimezone, [SOUND] and

now let's look at start_pacific.

And there we go, so that's 18 o'clock or rather 6 o'clock.

And we're in our Pacific time zone.

If it's always best to work in UTC, how do we do this in the real world?

Well, we need to know where the data's coming from.

To illustrate this, let's let's add another couple of time zones to our mix.

We're gonna use our friends Auckland and Mumbai again.

So Auckland will be pytz.timezone, Pacific/Auckland.

So don't get US Pacific and Pacific/Auckland mixed up.

And Mumbai will be [SOUND] Asia/Calcutta.

It's like I said, all of India is in the same timezone, so

we can just use Calcutta instead of trying to find Mumbai or whatever.

Let's make a new time zone, and we're gonna make it here local in US time.

So, let's do apollo_13_naive.

[SOUND] So, this is when, Apollo 13 launched,

which is 1970, on April 11, at 14,

13 UTC time, sort of, all right?

So we're starting this as this local date time.

So we, we have this time.

Sorry, and we wanna convert this to Eastern, so

apollo_13_eastern will be Eastern.localize, apollo_13_naive.

Okay, so if we look at apollo_13_naive, and

apollo _13_eastern, we have the same time.

Because that's, that was when it was launched.

Right? Two in the afternoon.

'Kay, so there's our eastern version.

Now, like I said,

we should be starting this as UTC for all of our around the world conversions.

So why do we wanna store it as UTC?

Well, it's because UTC doesn't deal with daylight saving times.

So, converting into and out of DST isn't as hard

as it is if you have to remember whether or not the original time is in DST.

If you'll going to [UNKNOWN], like fewer calculations have to worry about.

Not to mention the fact that some countries go in to DST at different times

from other countries that are even in the same time zone.

Watch that video, time zones are ridiculous.

Okay.

So, let's make apollo_13_utc.

So we're going to do apollo_13_eastern.astimezone, utc.

So why do we start with apollo_13_eastern instead of apollo_13_naive?

Well naive doesn't know where it is,

so it doesn't know how to convert itself into UTC.

That's why we wanna start with Eastern.

That's quite a few steps just to get to having this UTC time.

But, now, we can find this time all over the world.

So let's see when Apollo 13 launched in the Pacific.

[SOUND] So it launched at 11:13.

Okay, cool.

When did it do that in Auckland?

[SOUND] It was the next day at seven in the morning.

Okay.

When did it do it in Mumbai?

[SOUND] That was the next day and it was right after midnight,

43 minutes after midnight.

So, so long as you start with UTC dates and times,

you can always generate new dates and times for

anywhere in the world without worrying about getting incorrect dates and times.

Your Tardis wants to work on UTC times.

Right?

Your Tardis will be able to get you where you wanna go as long as you

start with UTC.

But, wait a minute.

What if you don't know all of the time zones?

So, pytz actually has two really handy little bits for finding time zones.

There is pytz.alltimezones.

And this lists all the time zones,

which is this, this huge, huge list of time zones.

Or you can do pytz.country_timezones.

And you can pass in a country two letter code.

And you get back just the time zones for that country.

So you can see we've got all of our usual ones.

We've got some crazy ones in like, Indiana and North Dakota, and

then we've got some in like, Alaska.

All right.

That's pretty much it for pytz for right now.

Hopefully, pytz gives you some more confidence when working with times and

dates in Python.

There are some other great libraries out there for

working with this often confusing data that I'll link to in the teacher's notes.

Before our last video, use the pytz and date time documentation to build a script

that takes a date and time in your time zone, and then gives that time back

in six other time zones using our format string from this video.

I'll show you my solution in the next video,

and the format string is in the teacher's notes.