WEBVTT

1
00:00:00.000 --> 00:00:07.350
ok so moving on now to talk about
date time now if we are dealing with dates rather

2
00:00:07.350 --> 00:00:11.650
than just times and we want to actually
do just we are going to use the date time

3
00:00:11.650 --> 00:00:16.590
module so in the previous video we talked a lot
about time but if you dealing with

4
00:00:16.590 --> 00:00:20.730
dates rather than just times it's
probably better to use the DateTime

5
00:00:20.730 --> 00:00:26.430
module even if time does include dates as
you saw in the previous video before we

6
00:00:26.430 --> 00:00:30.349
go on to the datetime module we're going
to have a quick look at the time zone

7
00:00:30.349 --> 00:00:34.210
support that exists in the time module
now we can get information on the

8
00:00:34.210 --> 00:00:40.030
current time zone via time.timezone and time.tzedname now these

9
00:00:40.030 --> 00:00:46.230
aren't functions timezone returns a number of
seconds offset from UTC so in other

10
00:00:46.230 --> 00:00:49.590
words it will be negative for country's east of the Greenwich Meridian

11
00:00:49.590 --> 00:00:54.890
and most of Western Europe and positive for the country's west of Greenwich in the

12
00:00:54.890 --> 00:01:00.329
UK for example it is 0 so it uses the non day light saving time DST time when

13
00:01:00.329 --> 00:01:04.229
calculating the offset which means that
you also have to check to see if daylight

14
00:01:04.229 --> 00:01:09.409
savings in effect and if it is to apply
that correction also now tzed name returns

15
00:01:09.409 --> 00:01:15.049
a tuple containing two strings
the name of the non dst timezone and

16
00:01:15.049 --> 00:01:20.890
also the name of the DST time zone
now before relying on the DST timezone name

17
00:01:20.890 --> 00:01:25.570
we need to check the value of time.daylight if this is non-zero

18
00:01:25.570 --> 00:01:30.270
then a DST timezone is defined and you can
trust that at that point the second string

19
00:01:30.270 --> 00:01:34.420
in the tzed name tuple otherwise
you shouldn't use the second string and

20
00:01:34.420 --> 00:01:38.430
you'll see how to use this shortly so what we
gonna do is we are going to print out a couple

21
00:01:38.430 --> 00:01:43.479
of examples and use these functions so
let's go and start doing that now and

22
00:01:43.479 --> 00:01:48.090
you can see that I've created a new
project called dates and datetime and

23
00:01:48.090 --> 00:01:53.930
created a new Python file called dateandtime.py so lets start by importing...

24
00:01:53.930 --> 00:02:03.890
....

25
00:02:03.890 --> 00:02:07.670
...remember we talk about epoch in previous videos.....

26
00:02:07.670 --> 00:02:18.690
.....

27
00:02:18.690 --> 00:02:23.099
making sure you are typing it in lower case because it

28
00:02:23.099 --> 00:02:27.489
does make a difference and for the first we are going to use...

29
00:02:27.489 --> 00:02:32.420
0 going back to the first possible date
if you recalled again we discuss that in a

30
00:02:32.420 --> 00:02:37.959
previous video on the next line let's
do the current time zone so...

31
00:02:37.959 --> 00:02:38.800
....

32
00:02:38.800 --> 00:02:42.750
...in adelaide australia because obviously this
is where the video is being recorded

33
00:02:42.750 --> 00:02:52.610
from so the current timezone is and we'll use a replacement field 0 with an off set of 1

34
00:02:52.610 --> 00:02:59.269
.....

35
00:02:59.269 --> 00:03:08.690
....to obtain the current timezone

36
00:03:08.690 --> 00:03:15.910
and just as a reminder if you go back to the
documentation do search i mean the in time

37
00:03:15.910 --> 00:03:21.660
help which we've seen in a previous
video if we do a searched for STR if time

38
00:03:21.660 --> 00:03:29.660
on that page you can see the various
parameters that are actually

39
00:03:29.660 --> 00:03:32.920
are supported and you saw that I've use local as the appropriate DateTime

40
00:03:32.920 --> 00:03:39.070
representation %c back to the code is you can see it on line 3 so

41
00:03:39.070 --> 00:03:42.500
that's where that's coming from and
we've also then printed out of the

42
00:03:42.500 --> 00:03:47.260
time zone and of set which I've talk about the
first tuple tzedname and then also

43
00:03:47.260 --> 00:03:52.329
the timezone but remember we need to
check that first to see where the

44
00:03:52.329 --> 00:03:58.230
daylight saving is in effect so put...

45
00:03:58.230 --> 00:04:03.120
.....

46
00:04:03.120 --> 00:04:13.690
...and I can tell you

47
00:04:13.690 --> 00:04:17.810
now in Australia in January when I'm
recording this video daylight saving

48
00:04:17.810 --> 00:04:21.199
is in effect so we should get
confirmation of that but obviously if

49
00:04:21.199 --> 00:04:26.290
you run this in your part of the world
and daylight saving isn't in effect you will probably get it you

50
00:04:26.290 --> 00:04:33.590
or you should get a different result and the
DST time zone is...

51
00:04:33.590 --> 00:04:39.020
remembering that is the second part the first part we can use which we defined or we

52
00:04:39.020 --> 00:04:44.180
showed outputted on line 5 but remember that
we said you need to check daylight

53
00:04:44.180 --> 00:04:47.560
saving time and if it is in effect in
other words in other words if it's not

54
00:04:47.560 --> 00:04:52.419
equal to 0 then and only then can you use
the second one the second string which

55
00:04:52.419 --> 00:04:56.430
is basically the DST timezone
otherwise it's not necessarily going to

56
00:04:56.430 --> 00:05:02.220
return a valid response ok so
moving lets print out local time so

57
00:05:02.220 --> 00:05:11.190
I'm going to... and we

58
00:05:11.190 --> 00:05:12.810
can do something like this we can go...

59
00:05:12.810 --> 00:05:20.200
.....

60
00:05:20.200 --> 00:05:26.720
....

61
00:05:26.720 --> 00:05:31.610
...you can probably guess what this is
going to do....I'm going to have no

62
00:05:31.610 --> 00:05:35.780
parameters for local time so it does
indeed return the right time and I'm going

63
00:05:35.780 --> 00:05:42.849
to copy the exact same string and exactly make a few
changes I'm going to change it to UTC time and down the end

64
00:05:42.849 --> 00:05:45.220
instead of time.localtime we change
that

65
00:05:45.220 --> 00:05:55.030
to...and if we go back to
the documentation you can see the

66
00:05:55.030 --> 00:05:58.919
various parameters that are used capital
Y year without century as

67
00:05:58.919 --> 00:06:02.780
a decimal number we also used to lower
case m month as a decimal number

68
00:06:02.780 --> 00:06:07.349
noting that if you use upper case M it is going to
give you the minutes and not the month which

69
00:06:07.349 --> 00:06:09.810
is why you want to check carefully
that your are choosing the right upper and lowercase

70
00:06:09.810 --> 00:06:16.060
characters that you have seen me enter and obviously the other ones are our

71
00:06:16.060 --> 00:06:22.690
captial M is for the minute and capital
S is for second ok enough talk

72
00:06:22.690 --> 00:06:29.090
lets run this application so I'm going to
right click it and run it and there's our output

73
00:06:29.090 --> 00:06:34.730
and you can see firstly the epoch on the
system starts on Thursday January

74
00:06:34.730 --> 00:06:39.300
1st 1970 we've discussed previously how that's like a standard date that a lot

75
00:06:39.300 --> 00:06:44.250
of date and time modules use as the starting
date the epoch in other words current

76
00:06:44.250 --> 00:06:48.790
timezone is a ACST that is Australian central
standard time because I'm in the middle

77
00:06:48.790 --> 00:06:54.280
of Australia with an offset of -34200 daylight saving time is in effect

78
00:06:54.280 --> 00:06:58.520
for this location and I mentioned that it
would be and should be because that is

79
00:06:58.520 --> 00:07:03.380
the case here in January in Australia
and the DST time zone is Australian

80
00:07:03.380 --> 00:07:09.330
central Daylight Time local time you
can see year is 2016 month is 01 for

81
00:07:09.330 --> 00:07:14.889
January the date is the 20th and its 3:49 p.m. in
the afternoon and note that the UTC

82
00:07:14.889 --> 00:07:18.600
time because obviously Adelaide time is
offset from that we are actually ahead of that

83
00:07:18.600 --> 00:07:21.430
time by nine and a half hours normally

84
00:07:21.430 --> 00:07:28.940
so the UTC time is 5:19 and going back and
looking at those parameters again looking

85
00:07:28.940 --> 00:07:33.870
at this %Z and the %z you might have been tempted

86
00:07:33.870 --> 00:07:38.150
to actually use those to display the
timezone offset in line 11 of the code

87
00:07:38.150 --> 00:07:45.169
and that's this line here the local time their on line 11 but keep in mind that

88
00:07:45.169 --> 00:07:48.990
the capital z has been deprecated in the time module much that means that you should

89
00:07:48.990 --> 00:07:53.370
avoid using it because it may be removed
from the language in the future and the

90
00:07:53.370 --> 00:07:57.669
other thing to mention is that the lower
case reversion isn't necessarily

91
00:07:57.669 --> 00:08:02.610
supported by all systems so if we go back and
have a look at the documentation

92
00:08:02.610 --> 00:08:08.700
and if we do a search for the lowercase version of percent z
it is giving a warning there about

93
00:08:08.700 --> 00:08:16.910
platform-specific but we will keep searching
right down the bottom you can see now the use of percent

94
00:08:16.910 --> 00:08:21.169
capital z is now deprecated but the
lowercase version the %z escape

95
00:08:21.169 --> 00:08:25.990
that expands to the preferred hour/minute offset is not supported by all ANSI

96
00:08:25.990 --> 00:08:29.480
C libraries so in other words you can't be
guaranteed that the code you

97
00:08:29.480 --> 00:08:33.440
write will give the same results on all
platforms and obviously that's a bad

98
00:08:33.440 --> 00:08:35.080
thing so keep that in mind as well

99
00:08:35.080 --> 00:08:38.419
incidentally they don't really make any
mention of the fact that percent lower

100
00:08:38.419 --> 00:08:46.290
z and the date time string have a timer function saying in their in that it shouldn't be used but we are only knowing it now that's the case

101
00:08:46.290 --> 00:08:52.050
ok so let's move on to date time now so what I'm going to do is comment the code out

102
00:08:52.050 --> 00:08:58.120
and I am going to start by using
some date time modules now functions from

103
00:08:58.120 --> 00:09:03.740
the date time module I should say now before I start the date time module documentation and I'm going to bring it on the

104
00:09:03.740 --> 00:09:08.710
screen and you can see the link there on
the screen to that date time module

105
00:09:08.710 --> 00:09:12.370
now there is talk in there if you want to actually
have a look at it and read it talks

106
00:09:12.370 --> 00:09:16.920
about naive and a where date and time
objects what that actually means is that

107
00:09:16.920 --> 00:09:23.250
a where objects are aware of the time
zone offset projects and naive objects aren't aware of that

108
00:09:23.250 --> 00:09:28.390
so date objects are naive and DateTime objects
can be aware so because timezone aware

109
00:09:28.390 --> 00:09:33.090
objects are slightly more complicated
we're going to cover them here and if you

110
00:09:33.090 --> 00:09:37.230
want to use date objects they work
exactly the same pretty much but you

111
00:09:37.230 --> 00:09:41.040
can ignore anything to do with time
zones in DST daylight saving time

112
00:09:41.040 --> 00:09:46.410
when using those so let's start with some
simple examples of using date time and

113
00:09:46.410 --> 00:09:51.740
we're going to have a look at a couple
modules so lets have a look at the first one I'm gonna do a search for datetime

114
00:09:51.740 --> 00:10:00.610
and you will come up and see that there's a DateTime
objects so there is a date time module and

115
00:10:00.610 --> 00:10:05.550
there is also a date time class so consequently
to access them we type DateTime.

116
00:10:05.550 --> 00:10:08.260
datetime so that might be a little bit
confusing when you see that for the

117
00:10:08.260 --> 00:10:19.080
first time but I will show you in the code what I mean anyway but that is the way Python set this up so type...

118
00:10:19.080 --> 00:10:28.810
...now the 2 date time entries, the 1st one is the module the 2nd one is the class...

119
00:10:28.810 --> 00:10:52.450
...so let just run the code so on the last example

120
00:10:52.450 --> 00:10:57.490
UTC is now obviously gives us the UTC now if you
happen to be in the UK when you call

121
00:10:57.490 --> 00:11:01.070
this then all three commands will print
the same date and time allowing for a

122
00:11:01.070 --> 00:11:04.620
few milliseconds difference for the
commands to execute and you can see down

123
00:11:04.620 --> 00:11:10.820
here the milliseconds.21762 for the
first entry point .216700

124
00:11:10.820 --> 00:11:16.570
the elapse time is how long the Python
interpreter in IntelliJ took to

125
00:11:16.570 --> 00:11:20.230
process that particular line of code that's
what are the numbers right at the end aren't

126
00:11:20.230 --> 00:11:25.160
exactly the same but you can see in my
case the times are different and that's

127
00:11:25.160 --> 00:11:30.100
because I'm in a different time zone now
today the function today and the

128
00:11:30.100 --> 00:11:34.750
function now appeared to do the same thing
because you can see I've returned the same date

129
00:11:34.750 --> 00:11:39.090
and the same time other than the
milliseconds in the end but the now

130
00:11:39.090 --> 00:11:42.740
method can be more precise and more
importantly now allows us to specify

131
00:11:42.740 --> 00:11:48.420
a timezone by providing a tzed info
object now unfortunately if we read the

132
00:11:48.420 --> 00:11:53.000
documentation for tzed info and we can see
that Python's DateTime.tzed info is

133
00:11:53.000 --> 00:11:58.810
an abstract class

134
00:11:58.810 --> 00:12:11.120
and I'm just going to do a quick search for Python tzinfo actually it was was probably in that doc anyway so let's go back to have a look and there

135
00:12:11.120 --> 00:12:14.250
it is on the screen and I'll close the find window

136
00:12:14.250 --> 00:12:18.320
so it is an abstract base class for time zone
information systems now it probably

137
00:12:18.320 --> 00:12:21.370
doesn't make sense to you because we
haven't really talked about classes and

138
00:12:21.370 --> 00:12:25.250
that's going to be coming later in the
course what it means right now for

139
00:12:25.250 --> 00:12:29.560
us is that as far as we're concerned the
datetime.tzinfo object can't

140
00:12:29.560 --> 00:12:35.330
or cannot be created so it might seems very
odd but basically Python DateTime has

141
00:12:35.330 --> 00:12:39.150
the ability to cope with aware dates which
we talked about but the actual method

142
00:12:39.150 --> 00:12:44.480
required to do so is only defined by the
language and not implemented so part

143
00:12:44.480 --> 00:12:48.240
of the rationale for this seems to be
that the local time can actually mean

144
00:12:48.240 --> 00:12:52.510
different things to different people and
as a result it's best left to the

145
00:12:52.510 --> 00:12:57.100
developer to implement tzinfo in a way
that is meaningful to them now speaking

146
00:12:57.100 --> 00:13:00.910
of time zones and for a humorous and very
informative discussion on time zones I

147
00:13:00.910 --> 00:13:04.589
want to bring your attention to a 10 minute
video on YouTube that really does an

148
00:13:04.589 --> 00:13:08.960
excellent job of demonstrating the
problems with time zones so I'm going to bring

149
00:13:08.960 --> 00:13:25.930
this link up on the screen and will go to that video and skip the ad

150
00:13:25.930 --> 00:13:31.460
ok so there is the link at top so that's also in the Resources section
as all these links have been now I

151
00:13:31.460 --> 00:13:35.990
suggest you do take the time to really
watch this video this is the video that

152
00:13:35.990 --> 00:13:41.240
JP found for us and it really does go
through the problem with time and time

153
00:13:41.240 --> 00:13:46.220
zones and you learn a lot of time zones
and the inherent problems that exist

154
00:13:46.220 --> 00:13:50.459
with time zones in computers there is also
another link which may be interested in

155
00:13:50.459 --> 00:13:54.740
to at least a few of you and this relates
to the original discussions that

156
00:13:54.740 --> 00:14:00.270
the Python team had to implementing
the date time and that's all the way back in

157
00:14:00.270 --> 00:14:03.970
March 2002 and there's the link on the
screen for that so check the out as well

158
00:14:03.970 --> 00:14:05.870
for some of the issues and so forth

159
00:14:05.870 --> 00:14:10.740
that they had but if you watch this
video and I do suggest you go away and watch that now

160
00:14:10.740 --> 00:14:15.760
you probably come away very glad to
learn that there is a library available that

161
00:14:15.760 --> 00:14:20.140
deals with the complexity of time zones
and daylight saving time and it's not

162
00:14:20.140 --> 00:14:24.330
part of the standard library that comes
with Python but it's generally speaking

163
00:14:24.330 --> 00:14:28.000
considered to be the best approach to dealing
with time zones although there are

164
00:14:28.000 --> 00:14:33.630
other libraries available but we're going
to talk about that library and

165
00:14:33.630 --> 00:14:36.839
actually install it and then start
working with it in the next video