WEBVTT

1
00:00:01.680 --> 00:00:03.779
ok so let's continue on with our

2
00:00:03.779 --> 00:00:06.990
discussions about time zones now as you
ok so let's continue on with our

3
00:00:06.990 --> 00:00:09.450
saw it's fairly easy to convert UTC to
discussions about time zones now as you

4
00:00:09.450 --> 00:00:11.550
any local time using the python
saw it's fairly easy to convert UTC to

5
00:00:11.550 --> 00:00:14.190
timezone pytz but going the
any local time using the python

6
00:00:14.190 --> 00:00:16.439
other way does present a problem so
timezone pytz but going the

7
00:00:16.439 --> 00:00:17.970
that's converting local time back to
other way does present a problem so

8
00:00:17.970 --> 00:00:20.820
UTC so in the UK for example the clocks
that's converting local time back to

9
00:00:20.820 --> 00:00:23.340
went back one hour at two a.m. on sunday
UTC so in the UK for example the clocks

10
00:00:23.340 --> 00:00:26.670
25th of october 2015 so if you have
went back one hour at two a.m. on sunday

11
00:00:26.670 --> 00:00:29.640
a local time of 130 on that day and
25th of october 2015 so if you have

12
00:00:29.640 --> 00:00:31.470
there's no way to tell if that was 130
a local time of 130 on that day and

13
00:00:31.470 --> 00:00:33.480
that happened before the clocks changed
there's no way to tell if that was 130

14
00:00:33.480 --> 00:00:34.800
or afterwards of course I'm talking
that happened before the clocks changed

15
00:00:34.800 --> 00:00:37.410
daylight saving time so given a UTC
or afterwards of course I'm talking

16
00:00:37.410 --> 00:00:39.809
time python can tell which one it was
daylight saving time so given a UTC

17
00:00:39.809 --> 00:00:41.430
but it is possible to go the other way
time python can tell which one it was

18
00:00:41.430 --> 00:00:44.790
unless the time was also stored with its
but it is possible to go the other way

19
00:00:44.790 --> 00:00:46.980
timezone information and at times it
unless the time was also stored with its

20
00:00:46.980 --> 00:00:49.320
will be either gmt or BST which stands
timezone information and at times it

21
00:00:49.320 --> 00:00:51.780
for british summer time the long and the
will be either gmt or BST which stands

22
00:00:51.780 --> 00:00:53.280
short of it is that the safest way to
for british summer time the long and the

23
00:00:53.280 --> 00:00:55.649
deal with local times is to immediately
short of it is that the safest way to

24
00:00:55.649 --> 00:00:59.070
convert them to UTC when you get them in
deal with local times is to immediately

25
00:00:59.070 --> 00:01:01.379
working UTC only converting the back to
convert them to UTC when you get them in

26
00:01:01.379 --> 00:01:03.539
local time when you display them to the
working UTC only converting the back to

27
00:01:03.539 --> 00:01:05.579
users of your program so that may not be
local time when you display them to the

28
00:01:05.579 --> 00:01:07.710
something that you thought of before
users of your program so that may not be

29
00:01:07.710 --> 00:01:08.970
but it does make sense to do that
something that you thought of before

30
00:01:08.970 --> 00:01:11.369
again what we're talking about here is
but it does make sense to do that

31
00:01:11.369 --> 00:01:13.380
to immediately convert a timer your going to use
again what we're talking about here is

32
00:01:13.380 --> 00:01:16.020
locally to UTC when you get them
to immediately convert a timer your going to use

33
00:01:16.020 --> 00:01:17.850
so only work in UTC but then you convert
locally to UTC when you get them

34
00:01:17.850 --> 00:01:19.950
them back to the local time when you
so only work in UTC but then you convert

35
00:01:19.950 --> 00:01:21.930
want to display them to the users of
them back to the local time when you

36
00:01:21.930 --> 00:01:23.970
your program everything else they are all other
want to display them to the users of

37
00:01:23.970 --> 00:01:26.159
times it's actually UTC that really gets rid
your program everything else they are all other

38
00:01:26.159 --> 00:01:27.030
all lot of the problem
times it's actually UTC that really gets rid

39
00:01:27.030 --> 00:01:29.490
so in the first date time example all
all lot of the problem

40
00:01:29.490 --> 00:01:31.290
three of the times we printed out were
so in the first date time example all

41
00:01:31.290 --> 00:01:33.630
naive that was there's no time zone
three of the times we printed out were

42
00:01:33.630 --> 00:01:35.640
information associated with them all we
naive that was there's no time zone

43
00:01:35.640 --> 00:01:38.250
got was the local time or the UTC times
information associated with them all we

44
00:01:38.250 --> 00:01:40.979
now pytz is there to help us and it
got was the local time or the UTC times

45
00:01:40.979 --> 00:01:43.320
provides a localized function that can
now pytz is there to help us and it

46
00:01:43.320 --> 00:01:45.810
be used to convert naive local datetime
provides a localized function that can

47
00:01:45.810 --> 00:01:47.759
into an aware date time
be used to convert naive local datetime

48
00:01:47.759 --> 00:01:49.229
let's have a look at an example of how
into an aware date time

49
00:01:49.229 --> 00:01:51.720
to go about doing and for
let's have a look at an example of how

50
00:01:51.720 --> 00:01:53.490
this example we open up
to go about doing and for

51
00:01:53.490 --> 00:01:56.460
another python file new python file
this example we open up

52
00:01:56.460 --> 00:02:01.170
and we'll just call we will call it aware time
another python file new python file

53
00:02:01.170 --> 00:02:04.799
let's just start typing....
and we'll just call we will call it aware time

54
00:02:04.799 --> 00:02:09.119
...
let's just start typing....

55
00:02:09.119 --> 00:02:55.019
...
...

56
00:02:55.019 --> 00:02:58.230
run just to get us going local time
...

57
00:02:58.230 --> 00:03:02.639
and UTC time that's fine let's go
run just to get us going local time

58
00:03:02.639 --> 00:03:04.169
have a look at using this localized
and UTC time that's fine let's go

59
00:03:04.169 --> 00:03:05.430
functions so going to type....
have a look at using this localized

60
00:03:05.430 --> 00:03:07.469
....
functions so going to type....

61
00:03:07.469 --> 00:03:36.709
....
....

62
00:03:38.630 --> 00:03:41.000
....

63
00:03:41.000 --> 00:03:43.970
....
....

64
00:03:43.970 --> 00:03:50.600
....if you run that
....

65
00:03:50.600 --> 00:03:54.290
and see we got local timezone Utc now
....if you run that

66
00:03:54.290 --> 00:03:57.440
and lets do the second one for the UTC
and see we got local timezone Utc now

67
00:03:57.440 --> 00:04:02.990
aware times so...
and lets do the second one for the UTC

68
00:04:02.990 --> 00:04:04.160
...
aware times so...

69
00:04:04.160 --> 00:04:14.510
...
...

70
00:04:14.510 --> 00:04:17.209
...so if we run that
...

71
00:04:17.209 --> 00:04:19.310
again that now we can see the output for both
...so if we run that

72
00:04:19.310 --> 00:04:22.010
of them and you can now see that the where
again that now we can see the output for both

73
00:04:22.010 --> 00:04:23.690
dates are aware because they now included
of them and you can now see that the where

74
00:04:23.690 --> 00:04:25.880
offset from UTC that's the + on the
dates are aware because they now included

75
00:04:25.880 --> 00:04:26.450
end
offset from UTC that's the + on the

76
00:04:26.450 --> 00:04:27.890
strictly speaking the concept of a
end

77
00:04:27.890 --> 00:04:29.810
timezone for UTC doesn't really make sense
strictly speaking the concept of a

78
00:04:29.810 --> 00:04:32.660
but from a programming perspective you
timezone for UTC doesn't really make sense

79
00:04:32.660 --> 00:04:34.520
can see that would make life easier to
but from a programming perspective you

80
00:04:34.520 --> 00:04:37.490
treat UTC's as if it were a time zone but hang
can see that would make life easier to

81
00:04:37.490 --> 00:04:39.590
on both of the where times are
treat UTC's as if it were a time zone but hang

82
00:04:39.590 --> 00:04:42.380
showing their time zones as UTC which isn't
on both of the where times are

83
00:04:42.380 --> 00:04:44.420
really what we want at all
showing their time zones as UTC which isn't

84
00:04:44.420 --> 00:04:47.240
and that careful reading of the PYTZ
really what we want at all

85
00:04:47.240 --> 00:04:48.800
documentation which I'm going to bring
and that careful reading of the PYTZ

86
00:04:48.800 --> 00:04:51.400
up on the screen
documentation which I'm going to bring

87
00:04:51.470 --> 00:04:53.060
good idea to actually go have a look at

88
00:04:53.060 --> 00:04:54.440
that I'll just paste the link in there's
good idea to actually go have a look at

89
00:04:54.440 --> 00:04:55.520
a link there and you'll be able to see
that I'll just paste the link in there's

90
00:04:55.520 --> 00:04:58.490
that in the resources section of this
a link there and you'll be able to see

91
00:04:58.490 --> 00:05:01.640
video and if we do a search for
that in the resources section of this

92
00:05:01.640 --> 00:05:10.160
localized...you can see
video and if we do a search for

93
00:05:10.160 --> 00:05:12.320
that it points out that localize is used
localized...you can see

94
00:05:12.320 --> 00:05:14.600
as a naive date time with no time zone
that it points out that localize is used

95
00:05:14.600 --> 00:05:16.790
information down here on the screen
as a naive date time with no time zone

96
00:05:16.790 --> 00:05:18.770
so could probably be more
information down here on the screen

97
00:05:18.770 --> 00:05:20.930
specific but instead it's left for us to
so could probably be more

98
00:05:20.930 --> 00:05:23.120
realize that if the original date time
specific but instead it's left for us to

99
00:05:23.120 --> 00:05:24.920
hasn't got time zone
realize that if the original date time

100
00:05:24.920 --> 00:05:26.870
information itself then pytz is going to
hasn't got time zone

101
00:05:26.870 --> 00:05:28.910
have a hard time working out what it
information itself then pytz is going to

102
00:05:28.910 --> 00:05:31.130
should be at all so all it can really do
have a hard time working out what it

103
00:05:31.130 --> 00:05:32.810
is provide an offset and set the time
should be at all so all it can really do

104
00:05:32.810 --> 00:05:35.990
zone to UTC not particularly useful in
is provide an offset and set the time

105
00:05:35.990 --> 00:05:37.880
our case but fortunately the standard
zone to UTC not particularly useful in

106
00:05:37.880 --> 00:05:40.130
datetime module provides an as time zone
our case but fortunately the standard

107
00:05:40.130 --> 00:05:42.800
method this converts and aware time to use
datetime module provides an as time zone

108
00:05:42.800 --> 00:05:45.530
the specified time zone or the local time zone
method this converts and aware time to use

109
00:05:45.530 --> 00:05:47.660
if none is given that is key there so the
the specified time zone or the local time zone

110
00:05:47.660 --> 00:05:49.370
correct way to deal with this is to take
if none is given that is key there so the

111
00:05:49.370 --> 00:05:51.530
the advice given above always work in
correct way to deal with this is to take

112
00:05:51.530 --> 00:05:52.280
UTC
the advice given above always work in

113
00:05:52.280 --> 00:05:55.460
and only convert to local time when
UTC

114
00:05:55.460 --> 00:05:56.960
you're displaying that time on the
and only convert to local time when

115
00:05:56.960 --> 00:05:59.120
screen to the user what that means is
you're displaying that time on the

116
00:05:59.120 --> 00:06:00.380
that we shouldn't be localizing the
screen to the user what that means is

117
00:06:00.380 --> 00:06:02.660
result of date time now but instead
that we shouldn't be localizing the

118
00:06:02.660 --> 00:06:05.480
using datetime . UTC now let's have a
result of date time now but instead

119
00:06:05.480 --> 00:06:09.050
look and change the code and see what
using datetime . UTC now let's have a

120
00:06:09.050 --> 00:06:09.590
happens
look and change the code and see what

121
00:06:09.590 --> 00:06:11.600
go back to intelliJ close this down
happens

122
00:06:11.600 --> 00:06:14.360
and looking at the code on line 10
go back to intelliJ close this down

123
00:06:14.360 --> 00:06:15.950
we're going at the end of that we're
and looking at the code on line 10

124
00:06:15.950 --> 00:06:21.710
going to put....so we still
we're going at the end of that we're

125
00:06:21.710 --> 00:06:24.590
localize UTC on line 10 as you can see so that
going to put....so we still

126
00:06:24.590 --> 00:06:26.570
it actually contains the time zone but
localize UTC on line 10 as you can see so that

127
00:06:26.570 --> 00:06:28.610
then we use the as timezone method to
it actually contains the time zone but

128
00:06:28.610 --> 00:06:30.800
convert it to a time zone we actually
then we use the as timezone method to

129
00:06:30.800 --> 00:06:32.870
want and defaulting at this stage for the
convert it to a time zone we actually

130
00:06:32.870 --> 00:06:34.520
computer local time because we didn't
want and defaulting at this stage for the

131
00:06:34.520 --> 00:06:36.860
provide a tz info in the
computer local time because we didn't

132
00:06:36.860 --> 00:06:38.750
brackets there's as a parameter so if we
provide a tz info in the

133
00:06:38.750 --> 00:06:43.250
run this you can see the time zone has now
brackets there's as a parameter so if we

134
00:06:43.250 --> 00:06:45.500
defaulted + 10 30 which is what is in
run this you can see the time zone has now

135
00:06:45.500 --> 00:06:47.600
Australia without daylight saving time
defaulted + 10 30 which is what is in

136
00:06:47.600 --> 00:06:50.810
Adelaide central Daylight Australian
Australia without daylight saving time

137
00:06:50.810 --> 00:06:52.400
central daylight time is the timezone that I am in
Adelaide central Daylight Australian

138
00:06:52.400 --> 00:06:55.910
and it's normally plus 9 30 but
central daylight time is the timezone that I am in

139
00:06:55.910 --> 00:06:57.830
in day light saving time we add an hour
and it's normally plus 9 30 but

140
00:06:57.830 --> 00:06:59.870
plus 10 30 so you can see it's defaulted
in day light saving time we add an hour

141
00:06:59.870 --> 00:07:02.900
successfully to the local timezone using
plus 10 30 so you can see it's defaulted

142
00:07:02.900 --> 00:07:04.760
the . as timezone method and of
successfully to the local timezone using

143
00:07:04.760 --> 00:07:06.770
course I didn't pass a tz info object
the . as timezone method and of

144
00:07:06.770 --> 00:07:08.419
so that's why it's just defaulted to
course I didn't pass a tz info object

145
00:07:08.419 --> 00:07:10.580
whichever time zone you're in so if
so that's why it's just defaulted to

146
00:07:10.580 --> 00:07:11.930
you run this on your computer you'll get
whichever time zone you're in so if

147
00:07:11.930 --> 00:07:14.000
your local timezone wherever or whatever
you run this on your computer you'll get

148
00:07:14.000 --> 00:07:16.400
part of the world you're actually in so
your local timezone wherever or whatever

149
00:07:16.400 --> 00:07:17.810
it's time to start thinking about the
part of the world you're actually in so

150
00:07:17.810 --> 00:07:19.520
challenge but before we start the
it's time to start thinking about the

151
00:07:19.520 --> 00:07:21.590
challenge i'm going to do is localize
challenge but before we start the

152
00:07:21.590 --> 00:07:24.440
2 UTC times and show how UTC can
challenge i'm going to do is localize

153
00:07:24.440 --> 00:07:27.410
copy with daylight savings time changes when the
2 UTC times and show how UTC can

154
00:07:27.410 --> 00:07:29.300
local time cannot which is pretty useful
copy with daylight savings time changes when the

155
00:07:29.300 --> 00:07:31.190
and so that we can really see what
local time cannot which is pretty useful

156
00:07:31.190 --> 00:07:32.720
happens we're going to use tiem stamps
and so that we can really see what

157
00:07:32.720 --> 00:07:35.510
that is second since epoch so the first
happens we're going to use tiem stamps

158
00:07:35.510 --> 00:07:36.950
step is to work at the number of seconds
that is second since epoch so the first

159
00:07:36.950 --> 00:07:38.870
we want to represent a datetime it falls
step is to work at the number of seconds

160
00:07:38.870 --> 00:07:41.570
into the gap caused by the DS time
we want to represent a datetime it falls

161
00:07:41.570 --> 00:07:42.470
change
into the gap caused by the DS time

162
00:07:42.470 --> 00:07:44.060
let's go ahead and do that we'll just
change

163
00:07:44.060 --> 00:07:45.380
put this code below so I'm going to
let's go ahead and do that we'll just

164
00:07:45.380 --> 00:07:50.450
start putting....
put this code below so I'm going to

165
00:07:50.450 --> 00:07:53.210
...
start putting....

166
00:07:53.210 --> 00:08:18.330
...
...

167
00:08:18.330 --> 00:08:24.870
...remembering that the
...

168
00:08:24.870 --> 00:08:26.340
reason I'm using that time is that falls
...remembering that the

169
00:08:26.340 --> 00:08:27.510
within the time that the clocks will
reason I'm using that time is that falls

170
00:08:27.510 --> 00:08:29.160
put back in the UK
within the time that the clocks will

171
00:08:29.160 --> 00:08:32.070
JP came up with that for us and
put back in the UK

172
00:08:32.070 --> 00:08:36.480
the actual number is 1445733000 so if
JP came up with that for us and

173
00:08:36.480 --> 00:08:39.480
you run this the number that should be
the actual number is 1445733000 so if

174
00:08:39.480 --> 00:08:42.750
coming back is 144573 triple zero
you run this the number that should be

175
00:08:42.750 --> 00:08:45.330
but this example is going to be
coming back is 144573 triple zero

176
00:08:45.330 --> 00:08:47.580
different depending where you run it so the reason
but this example is going to be

177
00:08:47.580 --> 00:08:49.170
for that is that it will only give you that
different depending where you run it so the reason

178
00:08:49.170 --> 00:08:51.090
number if you run on a computer set to gmt
for that is that it will only give you that

179
00:08:51.090 --> 00:08:53.010
time zone such as if you're in the UK
number if you run on a computer set to gmt

180
00:08:53.010 --> 00:08:55.620
during winter but that as i'm
time zone such as if you're in the UK

181
00:08:55.620 --> 00:08:57.720
recording this in adelaide i'm getting a
during winter but that as i'm

182
00:08:57.720 --> 00:08:58.920
completely different number the number
recording this in adelaide i'm getting a

183
00:08:58.920 --> 00:09:00.240
of course you can see on the screen is
completely different number the number

184
00:09:00.240 --> 00:09:04.800
1445698800 and of course if you run it
of course you can see on the screen is

185
00:09:04.800 --> 00:09:06.150
on your computer and you're in a
1445698800 and of course if you run it

186
00:09:06.150 --> 00:09:07.440
different times now you'll get a
on your computer and you're in a

187
00:09:07.440 --> 00:09:09.240
different numbers and this would make
different times now you'll get a

188
00:09:09.240 --> 00:09:10.710
more sense as we run the program so lets
different numbers and this would make

189
00:09:10.710 --> 00:09:12.570
just finish the program off now
more sense as we run the program so lets

190
00:09:12.570 --> 00:09:16.680
so what I'm going to do is set....
just finish the program off now

191
00:09:16.680 --> 00:09:22.320
...
so what I'm going to do is set....

192
00:09:22.320 --> 00:09:34.020
...
...

193
00:09:34.020 --> 00:09:39.810
...so we've created a new
...

194
00:09:39.810 --> 00:09:41.490
datetime object called gap time and
...so we've created a new

195
00:09:41.490 --> 00:09:45.120
initially represents 25th of october 2015 1:30 am
datetime object called gap time and

196
00:09:45.120 --> 00:09:48.090
being naive it contains a no zone
initially represents 25th of october 2015 1:30 am

197
00:09:48.090 --> 00:09:49.680
information and actually represents that
being naive it contains a no zone

198
00:09:49.680 --> 00:09:52.710
date time in local time so gap time is
information and actually represents that

199
00:09:52.710 --> 00:09:54.540
displayed both as a date and a unix
date time in local time so gap time is

200
00:09:54.540 --> 00:09:56.130
timestamp as you can see in depending on
displayed both as a date and a unix

201
00:09:56.130 --> 00:09:58.050
where you are around the world as i mentioned you
timestamp as you can see in depending on

202
00:09:58.050 --> 00:09:59.520
may or may not get the same result because it
where you are around the world as i mentioned you

203
00:09:59.520 --> 00:10:00.480
just really comes down to your local
may or may not get the same result because it

204
00:10:00.480 --> 00:10:03.360
timezone now the actual value we wanted
just really comes down to your local

205
00:10:03.360 --> 00:10:05.070
is hard-coded because unless you run the
timezone now the actual value we wanted

206
00:10:05.070 --> 00:10:07.050
program in the gmt time zone you may get
is hard-coded because unless you run the

207
00:10:07.050 --> 00:10:09.540
the right number so the value on
program in the gmt time zone you may get

208
00:10:09.540 --> 00:10:11.910
line 21 is the is the time for
the right number so the value on

209
00:10:11.910 --> 00:10:14.310
the correct time zone in the UK
line 21 is the is the time for

210
00:10:14.310 --> 00:10:16.890
and T which is set on line 22 we set
the correct time zone in the UK

211
00:10:16.890 --> 00:10:19.050
to one-hour greater than this and the way
and T which is set on line 22 we set

212
00:10:19.050 --> 00:10:21.930
we're doing that we're looking at s as
to one-hour greater than this and the way

213
00:10:21.930 --> 00:10:24.000
being equal to this date here remember it's
we're doing that we're looking at s as

214
00:10:24.000 --> 00:10:26.880
the number of seconds since epoc from 19
being equal to this date here remember it's

215
00:10:26.880 --> 00:10:29.370
which was first of january 19 to this
the number of seconds since epoc from 19

216
00:10:29.370 --> 00:10:31.470
date and we're adding basically adding
 which was first of january 19 to this

217
00:10:31.470 --> 00:10:35.400
an hour because 60 x 60 60 seconds
date and we're adding basically adding

218
00:10:35.400 --> 00:10:37.560
in a minute 60 minutes to an hour so adding
an hour because 60 x 60 60 seconds

219
00:10:37.560 --> 00:10:39.210
those two together
in a minute 60 minutes to an hour so adding

220
00:10:39.210 --> 00:10:41.970
t is going to be equal to that time
those two together

221
00:10:41.970 --> 00:10:44.100
there we define on line 17 plus 1 hour
t is going to be equal to that time

222
00:10:44.100 --> 00:10:46.980
which takes us past the daylight saving
there we define on line 17 plus 1 hour

223
00:10:46.980 --> 00:10:49.589
time change so we've done that what we want
which takes us past the daylight saving

224
00:10:49.589 --> 00:10:52.410
to do is want to create tz info object
time change so we've done that what we want

225
00:10:52.410 --> 00:10:55.230
so to do that we're gonna type...
to do is want to create tz info object

226
00:10:55.230 --> 00:10:59.640
....this time we
so to do that we're gonna type...

227
00:10:59.640 --> 00:11:02.040
are going to use a parameter and we're
....this time we

228
00:11:02.040 --> 00:11:05.760
going to type....
are going to use a parameter and we're

229
00:11:05.760 --> 00:11:08.040
...
going to type....

230
00:11:08.040 --> 00:11:12.390
...
...

231
00:11:12.390 --> 00:11:15.360
remembering s is the date defined on line 17
...

232
00:11:15.360 --> 00:11:16.830
or the number of seconds since epoch
remembering s is the date defined on line 17

233
00:11:16.830 --> 00:11:19.800
....then we want to convert it to a
or the number of seconds since epoch

234
00:11:19.800 --> 00:11:25.650
time zone......
....then we want to convert it to a

235
00:11:25.650 --> 00:11:28.950
gb on line 24 is
time zone......

236
00:11:28.950 --> 00:11:32.250
set to the time zones for the UK so
gb on line 24 is

237
00:11:32.250 --> 00:11:34.920
that's the first one that's before
set to the time zones for the UK so

238
00:11:34.920 --> 00:11:36.990
that's the 1 30 am from that date and
that's the first one that's before

239
00:11:36.990 --> 00:11:38.970
the dt2 i'll
that's the 1 30 am from that date and

240
00:11:38.970 --> 00:11:41.130
copy that and paste it
the dt2 i'll

241
00:11:41.130 --> 00:11:44.280
we're going to set that to the from
copy that and paste it

242
00:11:44.280 --> 00:11:46.020
timestamp its going to be T which of
we're going to set that to the from

243
00:11:46.020 --> 00:11:50.760
course is the one hour after and then
timestamp its going to be T which of

244
00:11:50.760 --> 00:11:52.890
what we want to do is print them out....
course is the one hour after and then

245
00:11:52.890 --> 00:11:56.570
...
what we want to do is print them out....

246
00:11:56.640 --> 00:12:07.350
...

247
00:12:07.350 --> 00:12:18.240
...
...

248
00:12:18.240 --> 00:12:19.650
so basically we've created a tz
...

249
00:12:19.650 --> 00:12:22.590
objects and localized the date-time
so basically we've created a tz

250
00:12:22.590 --> 00:12:24.180
objects we created from the from
objects and localized the date-time

251
00:12:24.180 --> 00:12:25.590
timestamp method which obviously
objects we created from the from

252
00:12:25.590 --> 00:12:27.690
converts from the second back to the
timestamp method which obviously

253
00:12:27.690 --> 00:12:29.940
valid date time object and then we're
converts from the second back to the

254
00:12:29.940 --> 00:12:32.280
using the as timezone but this time we
valid date time object and then we're

255
00:12:32.280 --> 00:12:34.650
specify the gb time zone using that
using the as timezone but this time we

256
00:12:34.650 --> 00:12:35.940
we're not using the default parameteres were
specify the gb time zone using that

257
00:12:35.940 --> 00:12:38.130
passing the gb timezone so we can
we're not using the default parameteres were

258
00:12:38.130 --> 00:12:40.890
calculate it in that time zone otherwise
passing the gb timezone so we can

259
00:12:40.890 --> 00:12:43.110
if you recall it locally it
calculate it in that time zone otherwise

260
00:12:43.110 --> 00:12:45.660
default to whatever the local time
if you recall it locally it

261
00:12:45.660 --> 00:12:47.130
zone is and we don't want to this case
default to whatever the local time

262
00:12:47.130 --> 00:12:49.680
because we specifically we're looking at
zone is and we don't want to this case

263
00:12:49.680 --> 00:12:55.890
doing this in UK time so if we run this you
because we specifically we're looking at

264
00:12:55.890 --> 00:12:57.690
find that the mistake we made here
doing this in UK time so if we run this you

265
00:12:57.690 --> 00:12:59.310
again looking at those results probably aren't what
find that the mistake we made here

266
00:12:59.310 --> 00:13:01.050
we thought they should be because
again looking at those results probably aren't what

267
00:13:01.050 --> 00:13:04.110
the time are completely out so we get
we thought they should be because

268
00:13:04.110 --> 00:13:05.700
as you can see there in the first case
the time are completely out so we get

269
00:13:05.700 --> 00:13:08.400
we're getting 11 a.m. a midday
as you can see there in the first case

270
00:13:08.400 --> 00:13:13.170
so 11am for s and 12 midday for t instead
we're getting 11 a.m. a midday

271
00:13:13.170 --> 00:13:16.800
of getting 130 am which is a little bit
so 11am for s and 12 midday for t instead

272
00:13:16.800 --> 00:13:18.690
weird if you think about it so the
of getting 130 am which is a little bit

273
00:13:18.690 --> 00:13:20.610
mistake we made is we've converted the
weird if you think about it so the

274
00:13:20.610 --> 00:13:23.010
time stamp using from time stamp method now
mistake we made is we've converted the

275
00:13:23.010 --> 00:13:25.050
the documentation states that this
time stamp using from time stamp method now

276
00:13:25.050 --> 00:13:27.750
returns the local date corresponding to
the documentation states that this

277
00:13:27.750 --> 00:13:29.880
the timestamps so what we've done is
returns the local date corresponding to

278
00:13:29.880 --> 00:13:31.410
we've not heeded the advice to always
the timestamps so what we've done is

279
00:13:31.410 --> 00:13:33.960
work in UTC in other words the local
we've not heeded the advice to always

280
00:13:33.960 --> 00:13:35.640
data is being involved in this which we
work in UTC in other words the local

281
00:13:35.640 --> 00:13:38.310
didn't want to happen so again as you
data is being involved in this which we

282
00:13:38.310 --> 00:13:39.870
can see the results weren't what we are
didn't want to happen so again as you

283
00:13:39.870 --> 00:13:41.700
expecting which would have been 1 30am
can see the results weren't what we are

284
00:13:41.700 --> 00:13:43.740
on that date taking account of daylight
expecting which would have been 1 30am

285
00:13:43.740 --> 00:13:44.910
saving time as well with the
on that date taking account of daylight

286
00:13:44.910 --> 00:13:48.030
beforehand and with the after this example
saving time as well with the

287
00:13:48.030 --> 00:13:51.060
was developed by JP and was
beforehand and with the after this example

288
00:13:51.060 --> 00:13:52.890
developed for the UK so it actually
was developed by JP and was

289
00:13:52.890 --> 00:13:53.880
work fine
developed for the UK so it actually

290
00:13:53.880 --> 00:13:55.500
so if you're doing something similar
work fine

291
00:13:55.500 --> 00:13:57.330
then the chances are you use your local
so if you're doing something similar

292
00:13:57.330 --> 00:13:58.890
timezone when you're doing your testing
then the chances are you use your local

293
00:13:58.890 --> 00:14:01.470
so you would see it working fine but of
timezone when you're doing your testing

294
00:14:01.470 --> 00:14:02.790
course when someone else wants to run
so you would see it working fine but of

295
00:14:02.790 --> 00:14:04.200
this like in my case I'm running this
course when someone else wants to run

296
00:14:04.200 --> 00:14:06.210
from a computer in Australia in a
this like in my case I'm running this

297
00:14:06.210 --> 00:14:08.100
completely different time zone it
from a computer in Australia in a

298
00:14:08.100 --> 00:14:10.560
doesn't work so you could see by that in
completely different time zone it

299
00:14:10.560 --> 00:14:12.630
this example errors like this can be
doesn't work so you could see by that in

300
00:14:12.630 --> 00:14:14.970
really difficult to spot because your
this example errors like this can be

301
00:14:14.970 --> 00:14:16.800
program appears to work when you tested
really difficult to spot because your

302
00:14:16.800 --> 00:14:18.509
in your time zone and you get the
program appears to work when you tested

303
00:14:18.509 --> 00:14:19.980
correct results but then of course when
in your time zone and you get the

304
00:14:19.980 --> 00:14:21.180
someone else runs it in a different
correct results but then of course when

305
00:14:21.180 --> 00:14:23.550
time zone they get different results
someone else runs it in a different

306
00:14:23.550 --> 00:14:25.500
it's only when you do that test in
time zone they get different results

307
00:14:25.500 --> 00:14:27.240
another time zone as we are seeing here or
it's only when you do that test in

308
00:14:27.240 --> 00:14:29.459
after daylight saving kicks in that you
another time zone as we are seeing here or

309
00:14:29.459 --> 00:14:32.069
start getting inconsistent results so if
after daylight saving kicks in that you

310
00:14:32.069 --> 00:14:33.870
you're dealing with international dates
start getting inconsistent results so if

311
00:14:33.870 --> 00:14:36.269
then virtual machines are really
you're dealing with international dates

312
00:14:36.269 --> 00:14:37.980
invaluable when testing your programs because
then virtual machines are really

313
00:14:37.980 --> 00:14:39.269
of course you can set those to
invaluable when testing your programs because

314
00:14:39.269 --> 00:14:41.190
different various time zones around the
of course you can set those to

315
00:14:41.190 --> 00:14:43.649
world and will do suggest you do that is
different various time zones around the

316
00:14:43.649 --> 00:14:45.180
dealing with program that uses a
world and will do suggest you do that is

317
00:14:45.180 --> 00:14:47.730
lot of dates and the great advantage of
dealing with program that uses a

318
00:14:47.730 --> 00:14:49.230
the doing that is you can run your program in
lot of dates and the great advantage of

319
00:14:49.230 --> 00:14:50.759
these various vms and make sure that
the doing that is you can run your program in

320
00:14:50.759 --> 00:14:52.920
your programs your code still perform should
these various vms and make sure that

321
00:14:52.920 --> 00:14:55.560
now to fix this program how do we go around
your programs your code still perform should

322
00:14:55.560 --> 00:14:58.350
fixing this because obviously we have got
now to fix this program how do we go around

323
00:14:58.350 --> 00:14:59.880
program that doesn't work we need to
fixing this because obviously we have got

324
00:14:59.880 --> 00:15:01.949
actually change the code on line 25
program that doesn't work we need to

325
00:15:01.949 --> 00:15:05.699
and 26 so where we've got from timestamp
actually change the code on line 25

326
00:15:05.699 --> 00:15:08.220
again from timestamp is using the local
and 26 so where we've got from timestamp

327
00:15:08.220 --> 00:15:10.410
date we want to use the UTC from
again from timestamp is using the local

328
00:15:10.410 --> 00:15:12.600
timestamp which make sure that we're
date we want to use the UTC from

329
00:15:12.600 --> 00:15:14.610
actually working in UTC all the time so
timestamp which make sure that we're

330
00:15:14.610 --> 00:15:19.050
we used the use so....you
actually working in UTC all the time so

331
00:15:19.050 --> 00:15:21.660
notices that methods is existing for
we used the use so....you

332
00:15:21.660 --> 00:15:25.800
us UTC and everything else be the same
notices that methods is existing for

333
00:15:25.800 --> 00:15:28.620
still being calculated but this initial
us UTC and everything else be the same

334
00:15:28.620 --> 00:15:31.019
calculation is now going to be correctly
still being calculated but this initial

335
00:15:31.019 --> 00:15:33.630
alculated in UTC so go ahead and
calculation is now going to be correctly

336
00:15:33.630 --> 00:15:36.389
run that you can now see that we
alculated in UTC so go ahead and

337
00:15:36.389 --> 00:15:37.800
actually got the correct results so both
run that you can now see that we

338
00:15:37.800 --> 00:15:40.860
time stamps display at the same date and time
actually got the correct results so both

339
00:15:40.860 --> 00:15:42.329
which we expected because of course the
time stamps display at the same date and time

340
00:15:42.329 --> 00:15:44.040
first one was before daylight saving
which we expected because of course the

341
00:15:44.040 --> 00:15:47.279
time which was 2 a.m. UK time so it
first one was before daylight saving

342
00:15:47.279 --> 00:15:49.380
because we've gone to daylight saving time
time which was 2 a.m. UK time so it

343
00:15:49.380 --> 00:15:52.829
in the second after second date the time
because we've gone to daylight saving time

344
00:15:52.829 --> 00:15:56.040
the variants has been adjusted back to 0 but
in the second after second date the time

345
00:15:56.040 --> 00:15:58.230
the actual time is the same for both so
the variants has been adjusted back to 0 but

346
00:15:58.230 --> 00:16:00.149
there's no offset the
the actual time is the same for both so

347
00:16:00.149 --> 00:16:03.120
offset 00 in the second example and its 01
there's no offset the

348
00:16:03.120 --> 00:16:04.319
in the first example because that's
offset 00 in the second example and its 01

349
00:16:04.319 --> 00:16:05.639
course that's how daylight saving time
in the first example because that's

350
00:16:05.639 --> 00:16:07.800
works when we actually convert it back
course that's how daylight saving time

351
00:16:07.800 --> 00:16:10.439
because basically the second example
works when we actually convert it back

352
00:16:10.439 --> 00:16:11.850
we are putting the clocks back one hour
because basically the second example

353
00:16:11.850 --> 00:16:13.089
for time zone
we are putting the clocks back one hour

354
00:16:13.089 --> 00:16:15.249
and the great example of this is now
for time zone

355
00:16:15.249 --> 00:16:17.170
that we make this change using the
and the great example of this is now

356
00:16:17.170 --> 00:16:19.120
UTC from time stamp and if you run this
that we make this change using the

357
00:16:19.120 --> 00:16:20.949
anywhere in the world because we're
UTC from time stamp and if you run this

358
00:16:20.949 --> 00:16:23.139
dealing in UTC time it's going to be
anywhere in the world because we're

359
00:16:23.139 --> 00:16:24.490
correct and it's actually going
dealing in UTC time it's going to be

360
00:16:24.490 --> 00:16:26.949
to work just fine i'm just about to wrap
correct and it's actually going

361
00:16:26.949 --> 00:16:28.329
up on this and then in the next video
to work just fine i'm just about to wrap

362
00:16:28.329 --> 00:16:29.410
we're going to go ahead and start the
up on this and then in the next video

363
00:16:29.410 --> 00:16:30.430
challenge
we're going to go ahead and start the

364
00:16:30.430 --> 00:16:32.170
do you want you to notice that the
challenge

365
00:16:32.170 --> 00:16:34.269
pytz module tz info objects
do you want you to notice that the

366
00:16:34.269 --> 00:16:36.009
can cope quite happily with this with
pytz module tz info objects

367
00:16:36.009 --> 00:16:38.319
this scenario of working no matter which
can cope quite happily with this with

368
00:16:38.319 --> 00:16:39.970
time zome it's running which is pretty
this scenario of working no matter which

369
00:16:39.970 --> 00:16:42.519
handy and although both date times in
time zome it's running which is pretty

370
00:16:42.519 --> 00:16:44.050
this example is displayed at the same
handy and although both date times in

371
00:16:44.050 --> 00:16:46.480
time I just want to be clear that the
this example is displayed at the same

372
00:16:46.480 --> 00:16:48.399
offsets are different here on the end of
time I just want to be clear that the

373
00:16:48.399 --> 00:16:50.350
this here this plus 01
offsets are different here on the end of

374
00:16:50.350 --> 00:16:51.999
this is before the clocks went back so
this here this plus 01

375
00:16:51.999 --> 00:16:54.160
the offset was plus one from UTC time
this is before the clocks went back so

376
00:16:54.160 --> 00:16:56.829
and the second time plus 00 was of course
the offset was plus one from UTC time

377
00:16:56.829 --> 00:16:58.930
when the clocks went back into UK time
and the second time plus 00 was of course

378
00:16:58.930 --> 00:17:01.569
after 2am it correctly put that back to
when the clocks went back into UK time

379
00:17:01.569 --> 00:17:02.589
00
after 2am it correctly put that back to

380
00:17:02.589 --> 00:17:04.809
that's it ok so I'm going to finish this
00

381
00:17:04.809 --> 00:17:07.120
video here in the next video we're going
that's it ok so I'm going to finish this

382
00:17:07.120 --> 00:17:09.699
to work on a challenge to help you
video here in the next video we're going

383
00:17:09.699 --> 00:17:11.649
understand what
to work on a challenge to help you

384
00:17:11.649 --> 00:17:13.539
you've been taught in these last couple
understand what

385
00:17:13.539 --> 00:17:16.149
of time zone videos and will see
you've been taught in these last couple

386
00:17:16.149 --> 00:17:19.319
you in that next videos
of time zone videos and will see