1
00:00:05,300 --> 00:00:10,630
ok so moving on now to talk about
date time now if we are dealing with dates rather

2
00:00:10,630 --> 00:00:14,930
than just times and we want to actually
do just we are going to use the date time

3
00:00:14,930 --> 00:00:19,870
module so in the previous video we talked a lot
about time but if you dealing with

4
00:00:19,870 --> 00:00:24,010
dates rather than just times it's
probably better to use the DateTime

5
00:00:24,010 --> 00:00:29,710
module even if time does include dates as
you saw in the previous video before we

6
00:00:29,710 --> 00:00:33,620
go on to the datetime module we're going
to have a quick look at the time zone

7
00:00:33,620 --> 00:00:37,490
support that exists in the time module
now we can get information on the

8
00:00:37,490 --> 00:00:43,310
current time zone via time.timezone and time.tzedname now these

9
00:00:43,310 --> 00:00:49,510
aren't functions timezone returns a number of
seconds offset from UTC so in other

10
00:00:49,510 --> 00:00:52,870
words it will be negative for country's east of the Greenwich Meridian

11
00:00:52,870 --> 00:00:58,170
and most of Western Europe and positive for the country's west of Greenwich in the

12
00:00:58,170 --> 00:01:03,600
UK for example it is 0 so it uses the non day light saving time DST time when

13
00:01:03,600 --> 00:01:07,500
calculating the offset which means that
you also have to check to see if daylight

14
00:01:07,500 --> 00:01:12,680
savings in effect and if it is to apply
that correction also now tzed name returns

15
00:01:12,680 --> 00:01:18,320
a tuple containing two strings
the name of the non dst timezone and

16
00:01:18,320 --> 00:01:24,170
also the name of the DST time zone
now before relying on the DST timezone name

17
00:01:24,170 --> 00:01:28,850
we need to check the value of time.daylight if this is non-zero

18
00:01:28,850 --> 00:01:33,550
then a DST timezone is defined and you can
trust that at that point the second string

19
00:01:33,550 --> 00:01:37,700
in the tzed name tuple otherwise
you shouldn't use the second string and

20
00:01:37,700 --> 00:01:41,710
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:41,710 --> 00:01:46,750
of examples and use these functions so
let's go and start doing that now and

22
00:01:46,750 --> 00:01:51,370
you can see that I've created a new
project called dates and datetime and

23
00:01:51,370 --> 00:01:57,210
created a new Python file called dateandtime.py so lets start by importing...

24
00:01:57,210 --> 00:02:07,170
....

25
00:02:07,170 --> 00:02:10,949
...remember we talk about epoch in previous videos.....

26
00:02:10,949 --> 00:02:21,970
.....

27
00:02:21,970 --> 00:02:26,370
making sure you are typing it in lower case because it

28
00:02:26,370 --> 00:02:30,760
does make a difference and for the first we are going to use...

29
00:02:30,760 --> 00:02:35,700
0 going back to the first possible date
if you recalled again we discuss that in a

30
00:02:35,700 --> 00:02:41,230
previous video on the next line let's
do the current time zone so...

31
00:02:41,230 --> 00:02:42,080
....

32
00:02:42,080 --> 00:02:46,030
...in adelaide australia because obviously this
is where the video is being recorded

33
00:02:46,030 --> 00:02:55,890
from so the current timezone is and we'll use a replacement field 0 with an off set of 1

34
00:02:55,890 --> 00:03:02,540
.....

35
00:03:02,540 --> 00:03:11,970
....to obtain the current timezone

36
00:03:11,970 --> 00:03:19,190
and just as a reminder if you go back to the
documentation do search i mean the in time

37
00:03:19,190 --> 00:03:24,940
help which we've seen in a previous
video if we do a searched for STR if time

38
00:03:24,940 --> 00:03:32,940
on that page you can see the various
parameters that are actually

39
00:03:32,940 --> 00:03:36,200
are supported and you saw that I've use local as the appropriate DateTime

40
00:03:36,200 --> 00:03:42,350
representation %c back to the code is you can see it on line 3 so

41
00:03:42,350 --> 00:03:45,780
that's where that's coming from and
we've also then printed out of the

42
00:03:45,780 --> 00:03:50,540
time zone and of set which I've talk about the
first tuple tzedname and then also

43
00:03:50,540 --> 00:03:55,600
the timezone but remember we need to
check that first to see where the

44
00:03:55,600 --> 00:04:01,510
daylight saving is in effect so put...

45
00:04:01,510 --> 00:04:06,400
.....

46
00:04:06,400 --> 00:04:16,970
...and I can tell you

47
00:04:16,970 --> 00:04:21,089
now in Australia in January when I'm
recording this video daylight saving

48
00:04:21,089 --> 00:04:24,470
is in effect so we should get
confirmation of that but obviously if

49
00:04:24,470 --> 00:04:29,570
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:29,570 --> 00:04:36,870
or you should get a different result and the
DST time zone is...

51
00:04:36,870 --> 00:04:42,300
remembering that is the second part the first part we can use which we defined or we

52
00:04:42,300 --> 00:04:47,460
showed outputted on line 5 but remember that
we said you need to check daylight

53
00:04:47,460 --> 00:04:50,840
saving time and if it is in effect in
other words in other words if it's not

54
00:04:50,840 --> 00:04:55,690
equal to 0 then and only then can you use
the second one the second string which

55
00:04:55,690 --> 00:04:59,710
is basically the DST timezone
otherwise it's not necessarily going to

56
00:04:59,710 --> 00:05:05,500
return a valid response ok so
moving lets print out local time so

57
00:05:05,500 --> 00:05:14,470
I'm going to... and we

58
00:05:14,470 --> 00:05:16,090
can do something like this we can go...

59
00:05:16,090 --> 00:05:23,480
.....

60
00:05:23,480 --> 00:05:30,000
....

61
00:05:30,000 --> 00:05:34,890
...you can probably guess what this is
going to do....I'm going to have no

62
00:05:34,890 --> 00:05:39,060
parameters for local time so it does
indeed return the right time and I'm going

63
00:05:39,060 --> 00:05:46,120
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:46,120 --> 00:05:48,500
instead of time.localtime we change
that

65
00:05:48,500 --> 00:05:58,310
to...and if we go back to
the documentation you can see the

66
00:05:58,310 --> 00:06:02,190
various parameters that are used capital
Y year without century as

67
00:06:02,190 --> 00:06:06,060
a decimal number we also used to lower
case m month as a decimal number

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

69
00:06:10,620 --> 00:06:13,090
is why you want to check carefully
that your are choosing the right upper and lowercase

70
00:06:13,090 --> 00:06:19,340
characters that you have seen me enter and obviously the other ones are our

71
00:06:19,340 --> 00:06:25,970
captial M is for the minute and capital
S is for second ok enough talk

72
00:06:25,970 --> 00:06:32,370
lets run this application so I'm going to
right click it and run it and there's our output

73
00:06:32,370 --> 00:06:38,010
and you can see firstly the epoch on the
system starts on Thursday January

74
00:06:38,010 --> 00:06:42,580
1st 1970 we've discussed previously how that's like a standard date that a lot

75
00:06:42,580 --> 00:06:47,530
of date and time modules use as the starting
date the epoch in other words current

76
00:06:47,530 --> 00:06:52,070
timezone is a ACST that is Australian central
standard time because I'm in the middle

77
00:06:52,070 --> 00:06:57,560
of Australia with an offset of -34200 daylight saving time is in effect

78
00:06:57,560 --> 00:07:01,800
for this location and I mentioned that it
would be and should be because that is

79
00:07:01,800 --> 00:07:06,660
the case here in January in Australia
and the DST time zone is Australian

80
00:07:06,660 --> 00:07:12,610
central Daylight Time local time you
can see year is 2016 month is 01 for

81
00:07:12,610 --> 00:07:18,160
January the date is the 20th and its 3:49 p.m. in
the afternoon and note that the UTC

82
00:07:18,160 --> 00:07:21,880
time because obviously Adelaide time is
offset from that we are actually ahead of that

83
00:07:21,880 --> 00:07:24,710
time by nine and a half hours normally

84
00:07:24,710 --> 00:07:32,220
so the UTC time is 5:19 and going back and
looking at those parameters again looking

85
00:07:32,220 --> 00:07:37,150
at this %Z and the %z you might have been tempted

86
00:07:37,150 --> 00:07:41,430
to actually use those to display the
timezone offset in line 11 of the code

87
00:07:41,430 --> 00:07:48,440
and that's this line here the local time their on line 11 but keep in mind that

88
00:07:48,440 --> 00:07:52,270
the capital z has been deprecated in the time module much that means that you should

89
00:07:52,270 --> 00:07:56,650
avoid using it because it may be removed
from the language in the future and the

90
00:07:56,650 --> 00:08:00,940
other thing to mention is that the lower
case reversion isn't necessarily

91
00:08:00,940 --> 00:08:05,890
supported by all systems so if we go back and
have a look at the documentation

92
00:08:05,890 --> 00:08:11,980
and if we do a search for the lowercase version of percent z
it is giving a warning there about

93
00:08:11,980 --> 00:08:20,190
platform-specific but we will keep searching
right down the bottom you can see now the use of percent

94
00:08:20,190 --> 00:08:24,440
capital z is now deprecated but the
lowercase version the %z escape

95
00:08:24,440 --> 00:08:29,270
that expands to the preferred hour/minute offset is not supported by all ANSI

96
00:08:29,270 --> 00:08:32,760
C libraries so in other words you can't be
guaranteed that the code you

97
00:08:32,760 --> 00:08:36,720
write will give the same results on all
platforms and obviously that's a bad

98
00:08:36,720 --> 00:08:38,360
thing so keep that in mind as well

99
00:08:38,360 --> 00:08:41,690
incidentally they don't really make any
mention of the fact that percent lower

100
00:08:41,690 --> 00:08:49,570
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:49,570 --> 00:08:55,330
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:55,330 --> 00:09:01,400
and I am going to start by using
some date time modules now functions from

103
00:09:01,400 --> 00:09:07,020
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:07,020 --> 00:09:11,990
screen and you can see the link there on
the screen to that date time module

105
00:09:11,990 --> 00:09:15,650
now there is talk in there if you want to actually
have a look at it and read it talks

106
00:09:15,650 --> 00:09:20,200
about naive and a where date and time
objects what that actually means is that

107
00:09:20,200 --> 00:09:26,530
a where objects are aware of the time
zone offset projects and naive objects aren't aware of that

108
00:09:26,530 --> 00:09:31,670
so date objects are naive and DateTime objects
can be aware so because timezone aware

109
00:09:31,670 --> 00:09:36,370
objects are slightly more complicated
we're going to cover them here and if you

110
00:09:36,370 --> 00:09:40,510
want to use date objects they work
exactly the same pretty much but you

111
00:09:40,510 --> 00:09:44,320
can ignore anything to do with time
zones in DST daylight saving time

112
00:09:44,320 --> 00:09:49,690
when using those so let's start with some
simple examples of using date time and

113
00:09:49,690 --> 00:09:55,020
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:55,020 --> 00:10:03,890
and you will come up and see that there's a DateTime
objects so there is a date time module and

115
00:10:03,890 --> 00:10:08,830
there is also a date time class so consequently
to access them we type DateTime.

116
00:10:08,830 --> 00:10:11,540
datetime so that might be a little bit
confusing when you see that for the

117
00:10:11,540 --> 00:10:22,360
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:22,360 --> 00:10:32,090
...now the 2 date time entries, the 1st one is the module the 2nd one is the class...

119
00:10:32,090 --> 00:10:55,730
...so let just run the code so on the last example

120
00:10:55,730 --> 00:11:00,770
UTC is now obviously gives us the UTC now if you
happen to be in the UK when you call

121
00:11:00,770 --> 00:11:04,350
this then all three commands will print
the same date and time allowing for a

122
00:11:04,350 --> 00:11:07,900
few milliseconds difference for the
commands to execute and you can see down

123
00:11:07,900 --> 00:11:14,100
here the milliseconds.21762 for the
first entry point .216700

124
00:11:14,100 --> 00:11:19,850
the elapse time is how long the Python
interpreter in IntelliJ took to

125
00:11:19,850 --> 00:11:23,510
process that particular line of code that's
what are the numbers right at the end aren't

126
00:11:23,510 --> 00:11:28,440
exactly the same but you can see in my
case the times are different and that's

127
00:11:28,440 --> 00:11:33,380
because I'm in a different time zone now
today the function today and the

128
00:11:33,380 --> 00:11:38,030
function now appeared to do the same thing
because you can see I've returned the same date

129
00:11:38,030 --> 00:11:42,370
and the same time other than the
milliseconds in the end but the now

130
00:11:42,370 --> 00:11:46,020
method can be more precise and more
importantly now allows us to specify

131
00:11:46,020 --> 00:11:51,700
a timezone by providing a tzed info
object now unfortunately if we read the

132
00:11:51,700 --> 00:11:56,280
documentation for tzed info and we can see
that Python's DateTime.tzed info is

133
00:11:56,280 --> 00:12:02,090
an abstract class

134
00:12:02,090 --> 00:12:14,400
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:14,400 --> 00:12:17,530
it is on the screen and I'll close the find window

136
00:12:17,530 --> 00:12:21,600
so it is an abstract base class for time zone
information systems now it probably

137
00:12:21,600 --> 00:12:24,650
doesn't make sense to you because we
haven't really talked about classes and

138
00:12:24,650 --> 00:12:28,530
that's going to be coming later in the
course what it means right now for

139
00:12:28,530 --> 00:12:32,840
us is that as far as we're concerned the
datetime.tzinfo object can't

140
00:12:32,840 --> 00:12:38,610
or cannot be created so it might seems very
odd but basically Python DateTime has

141
00:12:38,610 --> 00:12:42,430
the ability to cope with aware dates which
we talked about but the actual method

142
00:12:42,430 --> 00:12:47,760
required to do so is only defined by the
language and not implemented so part

143
00:12:47,760 --> 00:12:51,520
of the rationale for this seems to be
that the local time can actually mean

144
00:12:51,520 --> 00:12:55,790
different things to different people and
as a result it's best left to the

145
00:12:55,790 --> 00:13:00,380
developer to implement tzinfo in a way
that is meaningful to them now speaking

146
00:13:00,380 --> 00:13:04,190
of time zones and for a humorous and very
informative discussion on time zones I

147
00:13:04,190 --> 00:13:07,860
want to bring your attention to a 10 minute
video on YouTube that really does an

148
00:13:07,860 --> 00:13:12,240
excellent job of demonstrating the
problems with time zones so I'm going to bring

149
00:13:12,240 --> 00:13:29,210
this link up on the screen and will go to that video and skip the ad

150
00:13:29,210 --> 00:13:34,740
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:34,740 --> 00:13:39,270
suggest you do take the time to really
watch this video this is the video that

152
00:13:39,270 --> 00:13:44,520
JP found for us and it really does go
through the problem with time and time

153
00:13:44,520 --> 00:13:49,500
zones and you learn a lot of time zones
and the inherent problems that exist

154
00:13:49,500 --> 00:13:53,730
with time zones in computers there is also
another link which may be interested in

155
00:13:53,730 --> 00:13:58,020
to at least a few of you and this relates
to the original discussions that

156
00:13:58,020 --> 00:14:03,550
the Python team had to implementing
the date time and that's all the way back in

157
00:14:03,550 --> 00:14:07,250
March 2002 and there's the link on the
screen for that so check the out as well

158
00:14:07,250 --> 00:14:09,150
for some of the issues and so forth

159
00:14:09,150 --> 00:14:14,020
that they had but if you watch this
video and I do suggest you go away and watch that now

160
00:14:14,020 --> 00:14:19,040
you probably come away very glad to
learn that there is a library available that

161
00:14:19,040 --> 00:14:23,420
deals with the complexity of time zones
and daylight saving time and it's not

162
00:14:23,420 --> 00:14:27,610
part of the standard library that comes
with Python but it's generally speaking

163
00:14:27,610 --> 00:14:31,280
considered to be the best approach to dealing
with time zones although there are

164
00:14:31,280 --> 00:14:36,910
other libraries available but we're going
to talk about that library and

165
00:14:36,910 --> 00:14:40,110
actually install it and then start
working with it in the next video