1
00:00:05,560 --> 00:00:07,060
ok so let's continue on with our

2
00:00:07,060 --> 00:00:10,280
discussions about time zones now as you

3
00:00:10,280 --> 00:00:12,740
saw it's fairly easy to convert UTC to

4
00:00:12,740 --> 00:00:14,840
any local time using the python

5
00:00:14,840 --> 00:00:17,480
timezone pytz but going the

6
00:00:17,480 --> 00:00:19,720
other way does present a problem so

7
00:00:19,720 --> 00:00:21,260
that's converting local time back to

8
00:00:21,260 --> 00:00:24,110
UTC so in the UK for example the clocks

9
00:00:24,110 --> 00:00:26,630
went back one hour at two a.m. on sunday

10
00:00:26,630 --> 00:00:29,960
25th of october 2015 so if you have

11
00:00:29,960 --> 00:00:32,930
a local time of 130 on that day and

12
00:00:32,930 --> 00:00:34,760
there's no way to tell if that was 130

13
00:00:34,760 --> 00:00:36,770
that happened before the clocks changed

14
00:00:36,770 --> 00:00:38,090
or afterwards of course I'm talking

15
00:00:38,090 --> 00:00:40,700
daylight saving time so given a UTC

16
00:00:40,700 --> 00:00:43,090
time python can tell which one it was

17
00:00:43,090 --> 00:00:44,720
but it is possible to go the other way

18
00:00:44,720 --> 00:00:48,080
unless the time was also stored with its

19
00:00:48,080 --> 00:00:50,270
timezone information and at times it

20
00:00:50,270 --> 00:00:52,610
will be either gmt or BST which stands

21
00:00:52,610 --> 00:00:55,070
for british summer time the long and the

22
00:00:55,070 --> 00:00:56,570
short of it is that the safest way to

23
00:00:56,570 --> 00:00:58,930
deal with local times is to immediately

24
00:00:58,930 --> 00:01:02,360
convert them to UTC when you get them in

25
00:01:02,360 --> 00:01:04,660
working UTC only converting the back to

26
00:01:04,660 --> 00:01:06,820
local time when you display them to the

27
00:01:06,820 --> 00:01:08,860
users of your program so that may not be

28
00:01:08,860 --> 00:01:11,000
something that you thought of before

29
00:01:11,000 --> 00:01:12,260
but it does make sense to do that

30
00:01:12,260 --> 00:01:14,650
again what we're talking about here is

31
00:01:14,650 --> 00:01:16,670
to immediately convert a timer your going to use

32
00:01:16,670 --> 00:01:19,310
locally to UTC when you get them

33
00:01:19,310 --> 00:01:21,140
so only work in UTC but then you convert

34
00:01:21,140 --> 00:01:23,240
them back to the local time when you

35
00:01:23,240 --> 00:01:25,220
want to display them to the users of

36
00:01:25,220 --> 00:01:27,260
your program everything else they are all other

37
00:01:27,260 --> 00:01:29,440
times it's actually UTC that really gets rid

38
00:01:29,440 --> 00:01:30,320
all lot of the problem

39
00:01:30,320 --> 00:01:32,780
so in the first date time example all

40
00:01:32,780 --> 00:01:34,580
three of the times we printed out were

41
00:01:34,580 --> 00:01:36,920
naive that was there's no time zone

42
00:01:36,920 --> 00:01:38,930
information associated with them all we

43
00:01:38,930 --> 00:01:41,540
got was the local time or the UTC times

44
00:01:41,540 --> 00:01:44,260
now pytz is there to help us and it

45
00:01:44,260 --> 00:01:46,610
provides a localized function that can

46
00:01:46,610 --> 00:01:49,100
be used to convert naive local datetime

47
00:01:49,100 --> 00:01:51,040
into an aware date time

48
00:01:51,040 --> 00:01:52,510
let's have a look at an example of how

49
00:01:52,510 --> 00:01:55,010
to go about doing and for

50
00:01:55,010 --> 00:01:56,780
this example we open up

51
00:01:56,780 --> 00:01:59,750
another python file new python file

52
00:01:59,750 --> 00:02:04,460
and we'll just call we will call it aware time

53
00:02:04,460 --> 00:02:08,080
let's just start typing....

54
00:02:08,080 --> 00:02:12,400
...

55
00:02:12,400 --> 00:02:58,300
...

56
00:02:58,300 --> 00:03:01,520
run just to get us going local time

57
00:03:01,520 --> 00:03:05,920
and UTC time that's fine let's go

58
00:03:05,920 --> 00:03:07,450
have a look at using this localized

59
00:03:07,450 --> 00:03:08,720
functions so going to type....

60
00:03:08,720 --> 00:03:10,750
....

61
00:03:10,750 --> 00:03:39,990
....

62
00:03:41,920 --> 00:03:44,290
....

63
00:03:44,290 --> 00:03:47,260
....

64
00:03:47,260 --> 00:03:53,890
....if you run that

65
00:03:53,890 --> 00:03:57,580
and see we got local timezone Utc now

66
00:03:57,580 --> 00:04:00,730
and lets do the second one for the UTC

67
00:04:00,730 --> 00:04:06,280
aware times so...

68
00:04:06,280 --> 00:04:07,450
...

69
00:04:07,450 --> 00:04:17,800
...

70
00:04:17,800 --> 00:04:20,490
...so if we run that

71
00:04:20,490 --> 00:04:22,600
again that now we can see the output for both

72
00:04:22,600 --> 00:04:25,300
of them and you can now see that the where

73
00:04:25,300 --> 00:04:26,980
dates are aware because they now included

74
00:04:26,980 --> 00:04:29,170
offset from UTC that's the + on the

75
00:04:29,170 --> 00:04:29,740
end

76
00:04:29,740 --> 00:04:31,180
strictly speaking the concept of a

77
00:04:31,180 --> 00:04:33,100
timezone for UTC doesn't really make sense

78
00:04:33,100 --> 00:04:35,950
but from a programming perspective you

79
00:04:35,950 --> 00:04:37,810
can see that would make life easier to

80
00:04:37,810 --> 00:04:40,780
treat UTC's as if it were a time zone but hang

81
00:04:40,780 --> 00:04:42,880
on both of the where times are

82
00:04:42,880 --> 00:04:45,670
showing their time zones as UTC which isn't

83
00:04:45,670 --> 00:04:47,710
really what we want at all

84
00:04:47,710 --> 00:04:50,530
and that careful reading of the PYTZ

85
00:04:50,530 --> 00:04:52,090
documentation which I'm going to bring

86
00:04:52,090 --> 00:04:54,690
up on the screen

87
00:04:54,760 --> 00:04:56,350
good idea to actually go have a look at

88
00:04:56,350 --> 00:04:57,730
that I'll just paste the link in there's

89
00:04:57,730 --> 00:04:58,810
a link there and you'll be able to see

90
00:04:58,810 --> 00:05:01,780
that in the resources section of this

91
00:05:01,780 --> 00:05:04,930
video and if we do a search for

92
00:05:04,930 --> 00:05:13,450
localized...you can see

93
00:05:13,450 --> 00:05:15,610
that it points out that localize is used

94
00:05:15,610 --> 00:05:17,890
as a naive date time with no time zone

95
00:05:17,890 --> 00:05:20,080
information down here on the screen

96
00:05:20,080 --> 00:05:22,060
so could probably be more

97
00:05:22,060 --> 00:05:24,220
specific but instead it's left for us to

98
00:05:24,220 --> 00:05:26,410
realize that if the original date time

99
00:05:26,410 --> 00:05:28,210
hasn't got time zone

100
00:05:28,210 --> 00:05:30,160
information itself then pytz is going to

101
00:05:30,160 --> 00:05:32,200
have a hard time working out what it

102
00:05:32,200 --> 00:05:34,420
should be at all so all it can really do

103
00:05:34,420 --> 00:05:36,100
is provide an offset and set the time

104
00:05:36,100 --> 00:05:39,280
zone to UTC not particularly useful in

105
00:05:39,280 --> 00:05:41,170
our case but fortunately the standard

106
00:05:41,170 --> 00:05:43,420
datetime module provides an as time zone

107
00:05:43,420 --> 00:05:46,090
method this converts and aware time to use

108
00:05:46,090 --> 00:05:48,820
the specified time zone or the local time zone

109
00:05:48,820 --> 00:05:50,950
if none is given that is key there so the

110
00:05:50,950 --> 00:05:52,660
correct way to deal with this is to take

111
00:05:52,660 --> 00:05:54,820
the advice given above always work in

112
00:05:54,820 --> 00:05:55,570
UTC

113
00:05:55,570 --> 00:05:58,750
and only convert to local time when

114
00:05:58,750 --> 00:06:00,250
you're displaying that time on the

115
00:06:00,250 --> 00:06:02,410
screen to the user what that means is

116
00:06:02,410 --> 00:06:03,670
that we shouldn't be localizing the

117
00:06:03,670 --> 00:06:05,950
result of date time now but instead

118
00:06:05,950 --> 00:06:08,770
using datetime . UTC now let's have a

119
00:06:08,770 --> 00:06:12,340
look and change the code and see what

120
00:06:12,340 --> 00:06:12,880
happens

121
00:06:12,880 --> 00:06:14,890
go back to intelliJ close this down

122
00:06:14,890 --> 00:06:17,650
and looking at the code on line 10

123
00:06:17,650 --> 00:06:19,240
we're going at the end of that we're

124
00:06:19,240 --> 00:06:25,000
going to put....so we still

125
00:06:25,000 --> 00:06:27,880
localize UTC on line 10 as you can see so that

126
00:06:27,880 --> 00:06:29,860
it actually contains the time zone but

127
00:06:29,860 --> 00:06:31,900
then we use the as timezone method to

128
00:06:31,900 --> 00:06:34,090
convert it to a time zone we actually

129
00:06:34,090 --> 00:06:36,160
want and defaulting at this stage for the

130
00:06:36,160 --> 00:06:37,810
computer local time because we didn't

131
00:06:37,810 --> 00:06:40,150
provide a tz info in the

132
00:06:40,150 --> 00:06:42,040
brackets there's as a parameter so if we

133
00:06:42,040 --> 00:06:46,540
run this you can see the time zone has now

134
00:06:46,540 --> 00:06:48,790
defaulted + 10 30 which is what is in

135
00:06:48,790 --> 00:06:50,890
Australia without daylight saving time

136
00:06:50,890 --> 00:06:54,100
Adelaide central Daylight Australian

137
00:06:54,100 --> 00:06:55,690
central daylight time is the timezone that I am in

138
00:06:55,690 --> 00:06:59,200
and it's normally plus 9 30 but

139
00:06:59,200 --> 00:07:01,120
in day light saving time we add an hour

140
00:07:01,120 --> 00:07:03,160
plus 10 30 so you can see it's defaulted

141
00:07:03,160 --> 00:07:06,190
successfully to the local timezone using

142
00:07:06,190 --> 00:07:08,050
the . as timezone method and of

143
00:07:08,050 --> 00:07:10,060
course I didn't pass a tz info object

144
00:07:10,060 --> 00:07:11,700
so that's why it's just defaulted to

145
00:07:11,700 --> 00:07:13,870
whichever time zone you're in so if

146
00:07:13,870 --> 00:07:15,220
you run this on your computer you'll get

147
00:07:15,220 --> 00:07:17,290
your local timezone wherever or whatever

148
00:07:17,290 --> 00:07:19,690
part of the world you're actually in so

149
00:07:19,690 --> 00:07:21,100
it's time to start thinking about the

150
00:07:21,100 --> 00:07:22,810
challenge but before we start the

151
00:07:22,810 --> 00:07:24,880
challenge i'm going to do is localize

152
00:07:24,880 --> 00:07:27,730
2 UTC times and show how UTC can

153
00:07:27,730 --> 00:07:30,700
copy with daylight savings time changes when the

154
00:07:30,700 --> 00:07:32,590
local time cannot which is pretty useful

155
00:07:32,590 --> 00:07:34,480
and so that we can really see what

156
00:07:34,480 --> 00:07:36,010
happens we're going to use tiem stamps

157
00:07:36,010 --> 00:07:38,800
that is second since epoch so the first

158
00:07:38,800 --> 00:07:40,240
step is to work at the number of seconds

159
00:07:40,240 --> 00:07:42,160
we want to represent a datetime it falls

160
00:07:42,160 --> 00:07:44,860
into the gap caused by the DS time

161
00:07:44,860 --> 00:07:45,760
change

162
00:07:45,760 --> 00:07:47,350
let's go ahead and do that we'll just

163
00:07:47,350 --> 00:07:48,670
put this code below so I'm going to

164
00:07:48,670 --> 00:07:53,740
start putting....

165
00:07:53,740 --> 00:07:56,500
...

166
00:07:56,500 --> 00:08:21,620
...

167
00:08:21,620 --> 00:08:28,160
...remembering that the

168
00:08:28,160 --> 00:08:29,630
reason I'm using that time is that falls

169
00:08:29,630 --> 00:08:30,800
within the time that the clocks will

170
00:08:30,800 --> 00:08:32,450
put back in the UK

171
00:08:32,450 --> 00:08:35,360
JP came up with that for us and

172
00:08:35,360 --> 00:08:39,770
the actual number is 1445733000 so if

173
00:08:39,770 --> 00:08:42,770
you run this the number that should be

174
00:08:42,770 --> 00:08:46,040
coming back is 144573 triple zero

175
00:08:46,040 --> 00:08:48,620
but this example is going to be

176
00:08:48,620 --> 00:08:50,870
different depending where you run it so the reason

177
00:08:50,870 --> 00:08:52,460
for that is that it will only give you that

178
00:08:52,460 --> 00:08:54,380
number if you run on a computer set to gmt

179
00:08:54,380 --> 00:08:56,300
time zone such as if you're in the UK

180
00:08:56,300 --> 00:08:58,910
during winter but that as i'm

181
00:08:58,910 --> 00:09:01,010
recording this in adelaide i'm getting a

182
00:09:01,010 --> 00:09:02,210
completely different number the number

183
00:09:02,210 --> 00:09:03,530
of course you can see on the screen is

184
00:09:03,530 --> 00:09:08,090
1445698800 and of course if you run it

185
00:09:08,090 --> 00:09:09,440
on your computer and you're in a

186
00:09:09,440 --> 00:09:10,730
different times now you'll get a

187
00:09:10,730 --> 00:09:12,530
different numbers and this would make

188
00:09:12,530 --> 00:09:14,000
more sense as we run the program so lets

189
00:09:14,000 --> 00:09:15,860
just finish the program off now

190
00:09:15,860 --> 00:09:19,970
so what I'm going to do is set....

191
00:09:19,970 --> 00:09:25,610
...

192
00:09:25,610 --> 00:09:37,310
...

193
00:09:37,310 --> 00:09:43,100
...so we've created a new

194
00:09:43,100 --> 00:09:44,780
datetime object called gap time and

195
00:09:44,780 --> 00:09:48,410
initially represents 25th of october 2015 1:30 am

196
00:09:48,410 --> 00:09:51,380
being naive it contains a no zone

197
00:09:51,380 --> 00:09:52,970
information and actually represents that

198
00:09:52,970 --> 00:09:56,000
date time in local time so gap time is

199
00:09:56,000 --> 00:09:57,830
displayed both as a date and a unix

200
00:09:57,830 --> 00:09:59,420
timestamp as you can see in depending on

201
00:09:59,420 --> 00:10:01,340
where you are around the world as i mentioned you

202
00:10:01,340 --> 00:10:02,810
may or may not get the same result because it

203
00:10:02,810 --> 00:10:03,770
just really comes down to your local

204
00:10:03,770 --> 00:10:06,650
timezone now the actual value we wanted

205
00:10:06,650 --> 00:10:08,360
is hard-coded because unless you run the

206
00:10:08,360 --> 00:10:10,340
program in the gmt time zone you may get

207
00:10:10,340 --> 00:10:12,830
the right number so the value on

208
00:10:12,830 --> 00:10:15,200
line 21 is the is the time for

209
00:10:15,200 --> 00:10:17,600
the correct time zone in the UK

210
00:10:17,600 --> 00:10:20,180
and T which is set on line 22 we set
the correct time zone in the UK

211
00:10:20,180 --> 00:10:22,340
to one-hour greater than this and the way

212
00:10:22,340 --> 00:10:25,220
we're doing that we're looking at s as

213
00:10:25,220 --> 00:10:27,290
being equal to this date here remember it's

214
00:10:27,290 --> 00:10:30,170
the number of seconds since epoc from 19

215
00:10:30,170 --> 00:10:32,660
which was first of january 19 to this

216
00:10:32,660 --> 00:10:34,760
date and we're adding basically adding

217
00:10:34,760 --> 00:10:38,690
an hour because 60 x 60 60 seconds

218
00:10:38,690 --> 00:10:40,850
in a minute 60 minutes to an hour so adding

219
00:10:40,850 --> 00:10:42,500
those two together

220
00:10:42,500 --> 00:10:45,260
t is going to be equal to that time

221
00:10:45,260 --> 00:10:47,390
there we define on line 17 plus 1 hour

222
00:10:47,390 --> 00:10:50,270
which takes us past the daylight saving

223
00:10:50,270 --> 00:10:52,870
time change so we've done that what we want

224
00:10:52,870 --> 00:10:55,700
to do is want to create tz info object

225
00:10:55,700 --> 00:10:58,520
so to do that we're gonna type...

226
00:10:58,520 --> 00:11:02,930
....this time we

227
00:11:02,930 --> 00:11:05,330
are going to use a parameter and we're

228
00:11:05,330 --> 00:11:09,050
going to type....

229
00:11:09,050 --> 00:11:11,330
...

230
00:11:11,330 --> 00:11:15,680
...

231
00:11:15,680 --> 00:11:18,650
remembering s is the date defined on line 17

232
00:11:18,650 --> 00:11:20,120
or the number of seconds since epoch

233
00:11:20,120 --> 00:11:23,090
....then we want to convert it to a

234
00:11:23,090 --> 00:11:28,940
time zone......

235
00:11:28,940 --> 00:11:32,240
gb on line 24 is

236
00:11:32,240 --> 00:11:35,540
set to the time zones for the UK so

237
00:11:35,540 --> 00:11:38,210
that's the first one that's before

238
00:11:38,210 --> 00:11:40,280
that's the 1 30 am from that date and

239
00:11:40,280 --> 00:11:42,260
the dt2 i'll

240
00:11:42,260 --> 00:11:44,420
copy that and paste it

241
00:11:44,420 --> 00:11:47,570
we're going to set that to the from

242
00:11:47,570 --> 00:11:49,310
timestamp its going to be T which of

243
00:11:49,310 --> 00:11:54,050
course is the one hour after and then

244
00:11:54,050 --> 00:11:56,180
what we want to do is print them out....

245
00:11:56,180 --> 00:11:59,860
...

246
00:11:59,930 --> 00:12:10,640
...

247
00:12:10,640 --> 00:12:21,530
...

248
00:12:21,530 --> 00:12:22,940
so basically we've created a tz

249
00:12:22,940 --> 00:12:25,880
objects and localized the date-time

250
00:12:25,880 --> 00:12:27,470
objects we created from the from

251
00:12:27,470 --> 00:12:28,880
timestamp method which obviously

252
00:12:28,880 --> 00:12:30,980
converts from the second back to the

253
00:12:30,980 --> 00:12:33,230
valid date time object and then we're

254
00:12:33,230 --> 00:12:35,570
using the as timezone but this time we

255
00:12:35,570 --> 00:12:37,940
specify the gb time zone using that

256
00:12:37,940 --> 00:12:39,230
we're not using the default parameteres were

257
00:12:39,230 --> 00:12:41,420
passing the gb timezone so we can

258
00:12:41,420 --> 00:12:44,180
calculate it in that time zone otherwise

259
00:12:44,180 --> 00:12:46,400
if you recall it locally it

260
00:12:46,400 --> 00:12:48,950
default to whatever the local time

261
00:12:48,950 --> 00:12:50,420
zone is and we don't want to this case

262
00:12:50,420 --> 00:12:52,970
because we specifically we're looking at

263
00:12:52,970 --> 00:12:59,180
doing this in UK time so if we run this you

264
00:12:59,180 --> 00:13:00,980
find that the mistake we made here

265
00:13:00,980 --> 00:13:02,600
again looking at those results probably aren't what

266
00:13:02,600 --> 00:13:04,340
we thought they should be because

267
00:13:04,340 --> 00:13:07,400
the time are completely out so we get

268
00:13:07,400 --> 00:13:08,990
as you can see there in the first case

269
00:13:08,990 --> 00:13:11,690
we're getting 11 a.m. a midday

270
00:13:11,690 --> 00:13:16,460
so 11am for s and 12 midday for t instead

271
00:13:16,460 --> 00:13:20,090
of getting 130 am which is a little bit

272
00:13:20,090 --> 00:13:21,980
weird if you think about it so the

273
00:13:21,980 --> 00:13:23,900
mistake we made is we've converted the

274
00:13:23,900 --> 00:13:26,300
time stamp using from time stamp method now

275
00:13:26,300 --> 00:13:28,340
the documentation states that this

276
00:13:28,340 --> 00:13:31,040
returns the local date corresponding to

277
00:13:31,040 --> 00:13:33,170
the timestamps so what we've done is

278
00:13:33,170 --> 00:13:34,700
we've not heeded the advice to always

279
00:13:34,700 --> 00:13:37,250
work in UTC in other words the local

280
00:13:37,250 --> 00:13:38,930
data is being involved in this which we

281
00:13:38,930 --> 00:13:41,600
didn't want to happen so again as you

282
00:13:41,600 --> 00:13:43,160
can see the results weren't what we are

283
00:13:43,160 --> 00:13:44,990
expecting which would have been 1 30am

284
00:13:44,990 --> 00:13:47,030
on that date taking account of daylight

285
00:13:47,030 --> 00:13:48,200
saving time as well with the

286
00:13:48,200 --> 00:13:51,320
beforehand and with the after this example

287
00:13:51,320 --> 00:13:54,350
was developed by JP and was

288
00:13:54,350 --> 00:13:56,180
developed for the UK so it actually

289
00:13:56,180 --> 00:13:57,170
work fine

290
00:13:57,170 --> 00:13:58,790
so if you're doing something similar

291
00:13:58,790 --> 00:14:00,620
then the chances are you use your local

292
00:14:00,620 --> 00:14:02,180
timezone when you're doing your testing

293
00:14:02,180 --> 00:14:04,760
so you would see it working fine but of

294
00:14:04,760 --> 00:14:06,080
course when someone else wants to run

295
00:14:06,080 --> 00:14:07,490
this like in my case I'm running this

296
00:14:07,490 --> 00:14:09,500
from a computer in Australia in a

297
00:14:09,500 --> 00:14:11,390
completely different time zone it

298
00:14:11,390 --> 00:14:13,850
doesn't work so you could see by that in

299
00:14:13,850 --> 00:14:15,920
this example errors like this can be

300
00:14:15,920 --> 00:14:18,260
really difficult to spot because your

301
00:14:18,260 --> 00:14:20,090
program appears to work when you tested

302
00:14:20,090 --> 00:14:21,790
in your time zone and you get the

303
00:14:21,790 --> 00:14:23,270
correct results but then of course when

304
00:14:23,270 --> 00:14:24,470
someone else runs it in a different

305
00:14:24,470 --> 00:14:26,840
time zone they get different results

306
00:14:26,840 --> 00:14:28,790
it's only when you do that test in

307
00:14:28,790 --> 00:14:30,530
another time zone as we are seeing here or

308
00:14:30,530 --> 00:14:32,740
after daylight saving kicks in that you

309
00:14:32,740 --> 00:14:35,350
start getting inconsistent results so if

310
00:14:35,350 --> 00:14:37,160
you're dealing with international dates

311
00:14:37,160 --> 00:14:39,550
then virtual machines are really

312
00:14:39,550 --> 00:14:41,270
invaluable when testing your programs because

313
00:14:41,270 --> 00:14:42,550
of course you can set those to

314
00:14:42,550 --> 00:14:44,480
different various time zones around the

315
00:14:44,480 --> 00:14:46,930
world and will do suggest you do that is

316
00:14:46,930 --> 00:14:48,470
dealing with program that uses a

317
00:14:48,470 --> 00:14:51,020
lot of dates and the great advantage of

318
00:14:51,020 --> 00:14:52,520
the doing that is you can run your program in

319
00:14:52,520 --> 00:14:54,040
these various vms and make sure that

320
00:14:54,040 --> 00:14:56,210
your programs your code still perform should

321
00:14:56,210 --> 00:14:58,850
now to fix this program how do we go around

322
00:14:58,850 --> 00:15:01,640
fixing this because obviously we have got

323
00:15:01,640 --> 00:15:03,170
program that doesn't work we need to

324
00:15:03,170 --> 00:15:05,230
actually change the code on line 25

325
00:15:05,230 --> 00:15:08,980
and 26 so where we've got from timestamp

326
00:15:08,980 --> 00:15:11,510
again from timestamp is using the local

327
00:15:11,510 --> 00:15:13,700
date we want to use the UTC from

328
00:15:13,700 --> 00:15:15,890
timestamp which make sure that we're

329
00:15:15,890 --> 00:15:17,900
actually working in UTC all the time so

330
00:15:17,900 --> 00:15:22,340
we used the use so....you

331
00:15:22,340 --> 00:15:24,950
notices that methods is existing for

332
00:15:24,950 --> 00:15:29,090
us UTC and everything else be the same

333
00:15:29,090 --> 00:15:31,910
still being calculated but this initial

334
00:15:31,910 --> 00:15:34,300
calculation is now going to be correctly

335
00:15:34,300 --> 00:15:36,920
alculated in UTC so go ahead and

336
00:15:36,920 --> 00:15:39,670
run that you can now see that we

337
00:15:39,670 --> 00:15:41,090
actually got the correct results so both

338
00:15:41,090 --> 00:15:44,150
time stamps display at the same date and time

339
00:15:44,150 --> 00:15:45,610
which we expected because of course the

340
00:15:45,610 --> 00:15:47,330
first one was before daylight saving

341
00:15:47,330 --> 00:15:50,560
time which was 2 a.m. UK time so it

342
00:15:50,560 --> 00:15:52,670
because we've gone to daylight saving time

343
00:15:52,670 --> 00:15:56,110
in the second after second date the time

344
00:15:56,110 --> 00:15:59,330
the variants has been adjusted back to 0 but

345
00:15:59,330 --> 00:16:01,520
the actual time is the same for both so

346
00:16:01,520 --> 00:16:03,430
there's no offset the

347
00:16:03,430 --> 00:16:06,410
offset 00 in the second example and its 01

348
00:16:06,410 --> 00:16:07,600
in the first example because that's

349
00:16:07,600 --> 00:16:08,920
course that's how daylight saving time

350
00:16:08,920 --> 00:16:11,090
works when we actually convert it back

351
00:16:11,090 --> 00:16:13,720
because basically the second example

352
00:16:13,720 --> 00:16:15,140
we are putting the clocks back one hour

353
00:16:15,140 --> 00:16:16,370
for time zone

354
00:16:16,370 --> 00:16:18,530
and the great example of this is now

355
00:16:18,530 --> 00:16:20,460
that we make this change using the

356
00:16:20,460 --> 00:16:22,410
UTC from time stamp and if you run this

357
00:16:22,410 --> 00:16:24,230
anywhere in the world because we're

358
00:16:24,230 --> 00:16:26,420
dealing in UTC time it's going to be

359
00:16:26,420 --> 00:16:27,780
correct and it's actually going

360
00:16:27,780 --> 00:16:30,230
to work just fine i'm just about to wrap

361
00:16:30,230 --> 00:16:31,610
up on this and then in the next video

362
00:16:31,610 --> 00:16:32,700
we're going to go ahead and start the

363
00:16:32,700 --> 00:16:33,720
challenge

364
00:16:33,720 --> 00:16:35,460
do you want you to notice that the

365
00:16:35,460 --> 00:16:37,550
pytz module tz info objects

366
00:16:37,550 --> 00:16:39,290
can cope quite happily with this with

367
00:16:39,290 --> 00:16:41,600
this scenario of working no matter which

368
00:16:41,600 --> 00:16:43,260
time zome it's running which is pretty

369
00:16:43,260 --> 00:16:45,800
handy and although both date times in

370
00:16:45,800 --> 00:16:47,340
this example is displayed at the same

371
00:16:47,340 --> 00:16:49,770
time I just want to be clear that the

372
00:16:49,770 --> 00:16:51,680
offsets are different here on the end of

373
00:16:51,680 --> 00:16:53,640
this here this plus 01

374
00:16:53,640 --> 00:16:55,280
this is before the clocks went back so

375
00:16:55,280 --> 00:16:57,450
the offset was plus one from UTC time

376
00:16:57,450 --> 00:17:00,110
and the second time plus 00 was of course

377
00:17:00,110 --> 00:17:02,220
when the clocks went back into UK time

378
00:17:02,220 --> 00:17:04,849
after 2am it correctly put that back to

379
00:17:04,849 --> 00:17:05,869
00

380
00:17:05,869 --> 00:17:08,089
that's it ok so I'm going to finish this

381
00:17:08,089 --> 00:17:10,410
video here in the next video we're going

382
00:17:10,410 --> 00:17:12,980
to work on a challenge to help you

383
00:17:12,980 --> 00:17:14,930
understand what

384
00:17:14,930 --> 00:17:16,819
you've been taught in these last couple

385
00:17:16,819 --> 00:17:19,430
of time zone videos and will see

386
00:17:19,430 --> 00:17:22,599
you in that next videos