1 00:00:05,540 --> 00:00:06,580 Alright, in this video, 2 00:00:06,580 --> 00:00:08,410 we're gonna look at an alternative way 3 00:00:08,410 --> 00:00:10,710 to show the times in UTC times, 4 00:00:10,710 --> 00:00:13,200 and the other way of doing this is to use 5 00:00:13,200 --> 00:00:15,310 the SQLite date time functions 6 00:00:15,310 --> 00:00:17,750 and perform the conversion before actually getting 7 00:00:17,750 --> 00:00:20,030 the data back from the server, 8 00:00:20,030 --> 00:00:23,380 so I'm gonna change the query here in checkdb.py 9 00:00:23,380 --> 00:00:24,430 and then run the programme, 10 00:00:24,430 --> 00:00:26,120 and then we'll have a look at what's happening 11 00:00:26,120 --> 00:00:28,610 and refer to the SQLite documentation. 12 00:00:28,610 --> 00:00:30,970 So, we're no longer with this second example, 13 00:00:30,970 --> 00:00:34,660 need to import pytz, so I'm going to just delete that, 14 00:00:34,660 --> 00:00:36,750 and then we're gonna change the code. 15 00:00:36,750 --> 00:00:39,330 So, we're gonna start with the query, 16 00:00:39,330 --> 00:00:40,570 and the query's now going to be 17 00:00:40,570 --> 00:00:42,490 a little bit more complex than what it was before, 18 00:00:42,490 --> 00:00:43,530 so it's gonna be select, 19 00:00:43,530 --> 00:00:45,630 and I'll just delete this last part out. 20 00:00:45,630 --> 00:00:46,930 Type it again. 21 00:00:46,930 --> 00:00:51,100 SELECT strftime and then left print to say single quote, 22 00:00:52,300 --> 00:00:56,180 percent, capital Y, dash percent, lowercase m, 23 00:00:56,180 --> 00:00:58,930 dash percent, lowercase d, space, 24 00:01:00,130 --> 00:01:02,710 then percent, capital H, colon, 25 00:01:04,010 --> 00:01:06,550 percent, capital m, colon, 26 00:01:06,550 --> 00:01:08,390 percent, lowercase f, 27 00:01:08,390 --> 00:01:10,640 single quote, and then a semicolon, 28 00:01:10,640 --> 00:01:13,890 then a comma, then I'm gonna type history 29 00:01:13,890 --> 00:01:14,720 dot time, 30 00:01:17,850 --> 00:01:18,930 and localtime 31 00:01:21,330 --> 00:01:23,110 as localtime, 32 00:01:23,110 --> 00:01:27,030 comma, and then we'll go to the next line here. 33 00:01:28,180 --> 00:01:29,520 Then we're gonna do, then history. 34 00:01:29,520 --> 00:01:30,790 We're gonna space it at the start. 35 00:01:30,790 --> 00:01:34,080 History dot account, comma, space, 36 00:01:34,080 --> 00:01:35,660 history dot amount, 37 00:01:37,730 --> 00:01:38,820 from history, 38 00:01:41,160 --> 00:01:41,990 order by 39 00:01:43,800 --> 00:01:45,220 history dot time. 40 00:01:49,140 --> 00:01:50,930 And by the way, if you're getting this message 41 00:01:50,930 --> 00:01:53,960 popping up here, SQLite dialect is not configured, 42 00:01:53,960 --> 00:01:55,520 you can actually fix that easily enough. 43 00:01:55,520 --> 00:01:57,510 You can go into preferences or setup, 44 00:01:57,510 --> 00:02:00,420 depending on your operating system, 45 00:02:01,520 --> 00:02:04,100 and if you do a search for SQL, 46 00:02:05,250 --> 00:02:07,030 you should find SQL Dialects comes up. 47 00:02:07,030 --> 00:02:09,930 I click on that, and what we need to do is 48 00:02:09,930 --> 00:02:11,270 look at our particular files. 49 00:02:11,270 --> 00:02:12,940 In this case, checkdb. 50 00:02:12,940 --> 00:02:14,690 I come over here and click on that, 51 00:02:14,690 --> 00:02:17,390 and I can choose SQLite, so being specific, 52 00:02:17,390 --> 00:02:20,640 turning it to the dialect of SQL that we're gonna be using, 53 00:02:20,640 --> 00:02:22,100 and click OK. 54 00:02:22,100 --> 00:02:26,330 Once we do that, that warning disappears now, 55 00:02:26,330 --> 00:02:28,010 and then all we need to do now is 56 00:02:28,010 --> 00:02:29,930 I'm going to delete all of that, 57 00:02:29,930 --> 00:02:32,140 and then we're gonna just replace that, 58 00:02:32,140 --> 00:02:35,350 pretty simply, with print row, 59 00:02:35,350 --> 00:02:37,790 and we'll leave the db.close there. 60 00:02:37,790 --> 00:02:39,610 So let's actually just try running that 61 00:02:39,610 --> 00:02:41,890 to see whether it works, 62 00:02:41,890 --> 00:02:43,920 and you can see here, in this case, 63 00:02:43,920 --> 00:02:45,790 we get the dates back in my local time, 64 00:02:45,790 --> 00:02:47,840 or we've got SQLite, rather, 65 00:02:47,840 --> 00:02:50,080 to do the work for us. 66 00:02:50,080 --> 00:02:52,200 So this method has the advantage 67 00:02:52,200 --> 00:02:54,920 that it's gonna work whichever client is being used 68 00:02:54,920 --> 00:02:56,450 to access the database, 69 00:02:56,450 --> 00:02:59,100 so we could create a view with that select statement, 70 00:02:59,100 --> 00:03:01,040 and the data would be available to users 71 00:03:01,040 --> 00:03:03,510 in their local time, and you could use the view 72 00:03:03,510 --> 00:03:06,140 from the SQLite command line interface, for example, 73 00:03:06,140 --> 00:03:07,780 and get the same result. 74 00:03:07,780 --> 00:03:10,320 Now, we're gonna create creative view in a minute, 75 00:03:10,320 --> 00:03:13,550 but first, let's just have a look at what we've done. 76 00:03:13,550 --> 00:03:17,810 So, the select query uses the SQLite's strftime function, 77 00:03:17,810 --> 00:03:20,160 this one up here on line six, 78 00:03:20,160 --> 00:03:23,200 to convert the time field into a string. 79 00:03:23,200 --> 00:03:25,670 Now, we've seen how to use functions, such as count, 80 00:03:25,670 --> 00:03:27,040 earlier in this section, 81 00:03:27,040 --> 00:03:29,500 so here, we're just using a different function. 82 00:03:29,500 --> 00:03:32,880 Now, the first parameter to string f time 83 00:03:32,880 --> 00:03:37,130 is a format string, which determines the format 84 00:03:37,130 --> 00:03:40,270 for the date and time string that'll ultimately be produced, 85 00:03:40,270 --> 00:03:44,440 so next we provide a time value here in history.time, 86 00:03:45,470 --> 00:03:46,970 so we're getting that from the time column 87 00:03:46,970 --> 00:03:48,340 on the history table. 88 00:03:48,340 --> 00:03:52,330 We then provide a modifier, localtime in this case, 89 00:03:52,330 --> 00:03:54,400 and over here is the third argument, 90 00:03:54,400 --> 00:03:58,710 to cause the UTC time to be converted to local time. 91 00:03:58,710 --> 00:04:01,530 Now, the SQLite date time functions 92 00:04:01,530 --> 00:04:03,170 are documented quite well, 93 00:04:03,170 --> 00:04:04,510 so we just open that up. 94 00:04:04,510 --> 00:04:08,260 Gonna browse up, and the link is in the resources section. 95 00:04:08,260 --> 00:04:11,530 You can check that out at your leisure, 96 00:04:11,530 --> 00:04:14,990 and you can see strftime is there, 97 00:04:14,990 --> 00:04:17,490 so we do a search for that one 98 00:04:21,950 --> 00:04:23,770 and find out more information about it, 99 00:04:23,770 --> 00:04:25,930 or we can actually click on 100 00:04:25,930 --> 00:04:29,390 and see that it's based on the C version of the 101 00:04:29,390 --> 00:04:32,110 function of the same name. 102 00:04:32,110 --> 00:04:34,730 And the documentation states that 103 00:04:34,730 --> 00:04:36,650 there are five date and time functions, 104 00:04:36,650 --> 00:04:39,210 and obviously we've used the string f time. 105 00:04:39,210 --> 00:04:41,040 Now, that's strictly the only one that's necessary, 106 00:04:41,040 --> 00:04:42,890 the string f time, because all the others 107 00:04:42,890 --> 00:04:45,290 can be expressed using that one. 108 00:04:45,290 --> 00:04:47,860 The other functions are really just provided for convenience 109 00:04:47,860 --> 00:04:50,130 so that you don't have to mess around with format strings. 110 00:04:50,130 --> 00:04:52,310 Now, they may also be more efficient, 111 00:04:52,310 --> 00:04:56,000 because strftime is a more generic function. 112 00:04:56,000 --> 00:04:58,350 It has to pass the format string, for example, 113 00:04:58,350 --> 00:05:01,140 which makes it less efficient than the other methods, 114 00:05:01,140 --> 00:05:02,880 so you might be asking, at this point, 115 00:05:02,880 --> 00:05:05,600 why have I used string f time, or strftime, 116 00:05:05,600 --> 00:05:08,080 instead of datetime? 117 00:05:08,080 --> 00:05:10,590 I'll leave you to have a go at changing the query 118 00:05:10,590 --> 00:05:12,540 to use the datetime function instead. 119 00:05:12,540 --> 00:05:14,660 Just remember to remove the format string 120 00:05:14,660 --> 00:05:18,330 and refer to this documentation for the parameters. 121 00:05:18,330 --> 00:05:19,710 Now, when you get it working, 122 00:05:19,710 --> 00:05:22,190 notice that the seconds are displayed as whole seconds, 123 00:05:22,190 --> 00:05:25,590 with no fractional part, so it doesn't round either. 124 00:05:25,590 --> 00:05:29,210 It just truncates the fractional part. 125 00:05:29,210 --> 00:05:31,530 Now, in some applications, that'll be fine, 126 00:05:31,530 --> 00:05:32,720 but in our application, 127 00:05:32,720 --> 00:05:35,200 we need millisecond accuracy to ensure the transactions, 128 00:05:35,200 --> 00:05:39,190 or that transactions appear in the correct order. 129 00:05:39,190 --> 00:05:42,500 Now, in fact, the sharp eyed amongst you may have noticed 130 00:05:42,500 --> 00:05:44,240 that the SQLite function doesn't provide 131 00:05:44,240 --> 00:05:46,820 the same level of accuracy as the Python method. 132 00:05:46,820 --> 00:05:49,170 We'll just go back to the code now. 133 00:05:49,170 --> 00:05:51,800 The database is storing six decimals for the seconds, 134 00:05:51,800 --> 00:05:53,910 and we'll just confirm that. 135 00:05:53,910 --> 00:05:55,830 One two three four five six, 136 00:05:55,830 --> 00:05:57,750 after the dot 32, 137 00:05:57,750 --> 00:05:59,330 but in terms of our output, 138 00:05:59,330 --> 00:06:02,530 from the checkdb code that we've created, 139 00:06:02,530 --> 00:06:04,710 we're only seeing three decimal points. 140 00:06:04,710 --> 00:06:07,270 In other words, the SQLite date functions only work 141 00:06:07,270 --> 00:06:08,760 to three decimal places. 142 00:06:08,760 --> 00:06:11,040 Now, this is mentioned in the documentation. 143 00:06:11,040 --> 00:06:13,630 I won't go back to it now, but it's under the last paragraph 144 00:06:13,630 --> 00:06:15,730 in the time string section, 145 00:06:15,730 --> 00:06:18,270 and that's why I ordered our query by the time field, 146 00:06:18,270 --> 00:06:21,200 rather than from our calculated local field, 147 00:06:21,200 --> 00:06:23,650 so here, order by history.time 148 00:06:23,650 --> 00:06:27,240 instead of doing it with our calculated field here, 149 00:06:27,240 --> 00:06:28,410 which was localtime. 150 00:06:28,410 --> 00:06:30,070 That way, we're still getting the benefit 151 00:06:30,070 --> 00:06:33,320 of the six decimal points of precision. 152 00:06:33,320 --> 00:06:35,570 Now, the SQLite date functions only work, 153 00:06:35,570 --> 00:06:37,380 as you can see, to three decimal points. 154 00:06:37,380 --> 00:06:39,270 Now, this is mentioned in the documentation, 155 00:06:39,270 --> 00:06:42,300 which I will zip back to quickly, 156 00:06:42,300 --> 00:06:45,320 and it's under time strings, 157 00:06:45,320 --> 00:06:46,150 down here. 158 00:06:50,430 --> 00:06:52,360 So that's actually why I ordered our query 159 00:06:52,360 --> 00:06:54,730 by the time field, rather than from our 160 00:06:54,730 --> 00:06:56,560 calculated local time field, 161 00:06:56,560 --> 00:06:58,640 so just to show you what I mean. 162 00:06:58,640 --> 00:07:01,790 Say the SQLite order by clause on the line seven here 163 00:07:01,790 --> 00:07:04,060 is still using the history dot time field 164 00:07:04,060 --> 00:07:05,800 directly from the database, 165 00:07:05,800 --> 00:07:08,750 and we're not trying to order by this localtime, 166 00:07:08,750 --> 00:07:10,840 so as a result, we're still getting the time 167 00:07:10,840 --> 00:07:12,690 in the six decimal places instead of three, 168 00:07:12,690 --> 00:07:14,550 so it's more accurate. 169 00:07:14,550 --> 00:07:16,660 And just to confirm, if we open the history table, 170 00:07:16,660 --> 00:07:18,610 you can see that that is six decimal points 171 00:07:18,610 --> 00:07:21,470 of precision there, compared to the three that our output 172 00:07:21,470 --> 00:07:25,630 by the checkdb programme using this strftime function. 173 00:07:27,660 --> 00:07:29,700 I'll just go back to the documentation again, 174 00:07:29,700 --> 00:07:31,560 and just before we actually finish with it, 175 00:07:31,560 --> 00:07:34,500 the SQLite strftime function's format string 176 00:07:34,500 --> 00:07:37,530 behaves slightly differently to Python's, 177 00:07:37,530 --> 00:07:40,630 and it's quite actually hard to spot from the documentation, 178 00:07:40,630 --> 00:07:43,630 but if we do a search for percent f, 179 00:07:47,210 --> 00:07:48,770 see here, under fractional seconds, 180 00:07:48,770 --> 00:07:50,450 SS dot SSS, 181 00:07:50,450 --> 00:07:52,440 notice that it includes SS 182 00:07:52,440 --> 00:07:53,860 to the left of the decimal point, 183 00:07:53,860 --> 00:07:57,180 so percent f, when using the strftime function, 184 00:07:57,180 --> 00:08:00,930 will give you seconds and their fractional part. 185 00:08:00,930 --> 00:08:04,330 Now, if you use the Python strp time function, 186 00:08:04,330 --> 00:08:07,740 the percent f will only give you the fractional part. 187 00:08:07,740 --> 00:08:09,360 So in other words, in Python, 188 00:08:09,360 --> 00:08:11,880 we would need to use a percent capital S, 189 00:08:11,880 --> 00:08:15,730 dot percent f to get the full seconds value. 190 00:08:15,730 --> 00:08:17,950 Now, I mentioned earlier that it's important 191 00:08:17,950 --> 00:08:20,170 to refer to the correct set of documentation, 192 00:08:20,170 --> 00:08:21,730 and if you're using Python functions, 193 00:08:21,730 --> 00:08:25,680 make sure you use the Python SQLite3 library documentation, 194 00:08:25,680 --> 00:08:30,110 and when working with SQLite, use the SQLite documentation. 195 00:08:30,110 --> 00:08:31,830 Alright, so let's go back now to our code 196 00:08:31,830 --> 00:08:34,679 and create a view for this query, 197 00:08:34,679 --> 00:08:37,360 so we're gonna go back to rollback.py, 198 00:08:37,360 --> 00:08:41,120 and a place for adding the view is obviously there, 199 00:08:41,120 --> 00:08:43,440 because that's where we're creating the tables, 200 00:08:43,440 --> 00:08:45,390 so I'm gonna go back and copy all the text 201 00:08:45,390 --> 00:08:47,620 from db.execute onwards 202 00:08:47,620 --> 00:08:50,240 and paste it into rollback.py. 203 00:08:50,240 --> 00:08:52,790 Let's go back and do that, 204 00:08:52,790 --> 00:08:57,080 so I'm just gonna do db.execute and copy that, 205 00:08:57,080 --> 00:08:59,130 and go back to rollback.py. 206 00:08:59,130 --> 00:09:03,120 We're gonna put that below the two table creations 207 00:09:03,120 --> 00:09:06,120 and get rid of the colon on the end. 208 00:09:07,900 --> 00:09:10,230 So, now what we need to do is change that a little bit 209 00:09:10,230 --> 00:09:13,250 to create a view, rather than executing query, 210 00:09:13,250 --> 00:09:14,960 so I'm gonna add this at the start, 211 00:09:14,960 --> 00:09:18,710 instead of select, we're gonna do create view 212 00:09:20,020 --> 00:09:21,190 if not exists, 213 00:09:23,680 --> 00:09:25,010 localhistory as, 214 00:09:27,050 --> 00:09:29,320 and leave the rest of the lines in there, 215 00:09:29,320 --> 00:09:32,240 and we got a warning here about the line being too long, 216 00:09:32,240 --> 00:09:35,380 so I'm just going to split it there. 217 00:09:35,380 --> 00:09:38,140 And just to be complete, we need to put a space there 218 00:09:38,140 --> 00:09:40,380 to keep everything happy and make sure that 219 00:09:40,380 --> 00:09:44,200 we've got a relevant space so that the SQL code still works, 220 00:09:44,200 --> 00:09:46,760 and we'll also modify the connexion now, 221 00:09:46,760 --> 00:09:48,540 accounts dot sqlite. 222 00:09:48,540 --> 00:09:51,200 Let's also do that detect underscore types 223 00:09:51,200 --> 00:09:55,370 is equal to sqlite dot PARSE underscore DECLTYPES, 224 00:09:56,340 --> 00:09:57,790 which we talked about, 225 00:09:57,790 --> 00:09:59,670 and when we do that, we get this warning, 226 00:09:59,670 --> 00:10:01,910 which we can see over here, 227 00:10:01,910 --> 00:10:04,990 and we can fix that warning up if we want to 228 00:10:04,990 --> 00:10:07,780 by just going again into our preferences or settings, 229 00:10:07,780 --> 00:10:11,410 doing a search for SQL and go to SQL Dialects, 230 00:10:11,410 --> 00:10:13,180 and then we can select the file. 231 00:10:13,180 --> 00:10:15,850 In this case, rollback, and change that to SQLite too, 232 00:10:15,850 --> 00:10:17,710 just if you wanna get rid of the warning. 233 00:10:17,710 --> 00:10:19,020 It'll work without it, 234 00:10:19,020 --> 00:10:21,800 but it looks a bit nicer without any warnings. 235 00:10:21,800 --> 00:10:24,330 Alright, so let's clear the history table again. 236 00:10:24,330 --> 00:10:26,820 I'm going to select all four, 237 00:10:26,820 --> 00:10:29,670 delete them, and then save it. 238 00:10:29,670 --> 00:10:32,740 Obviously, we've got an empty history table there now. 239 00:10:32,740 --> 00:10:35,520 Alright, and we're going to run this 240 00:10:35,520 --> 00:10:38,190 so the view gets created. 241 00:10:38,190 --> 00:10:40,600 No errors, which is good, 242 00:10:40,600 --> 00:10:42,210 and if you go back now to checkdb, 243 00:10:42,210 --> 00:10:44,070 we can change the code from there, 244 00:10:44,070 --> 00:10:46,360 and let's do that and use the query, 245 00:10:46,360 --> 00:10:49,670 so I'm just gonna comment that code out. 246 00:10:49,670 --> 00:10:50,980 We've got a reference tool, 247 00:10:50,980 --> 00:10:55,070 and then we'll put instead for row in db.execute, 248 00:10:56,390 --> 00:11:00,790 and it's gonna be now SELECT star from localhistory 249 00:11:00,790 --> 00:11:03,310 being the name of our view. 250 00:11:03,310 --> 00:11:05,770 We should be able to run that now, 251 00:11:05,770 --> 00:11:07,610 with the same results. 252 00:11:07,610 --> 00:11:09,610 You can see, we've got the results now, 253 00:11:09,610 --> 00:11:11,420 and obviously it's been updated, 254 00:11:11,420 --> 00:11:13,240 'cause I'm running this at a later point 255 00:11:13,240 --> 00:11:15,080 in my local time. 256 00:11:15,080 --> 00:11:17,700 Now, we can go back to history and we can go to refresh. 257 00:11:17,700 --> 00:11:19,780 There's our entries, 258 00:11:19,780 --> 00:11:22,220 and again, you can see the six points of precision there, 259 00:11:22,220 --> 00:11:24,450 compared to three decimal points of precision 260 00:11:24,450 --> 00:11:25,610 from using the 261 00:11:26,950 --> 00:11:28,110 string f time, 262 00:11:29,980 --> 00:11:33,690 the strftime function, which is part of SQLite. 263 00:11:33,690 --> 00:11:35,620 So, again, we're still storing it, 264 00:11:35,620 --> 00:11:38,480 and you have the history table in UTC time, 265 00:11:38,480 --> 00:11:41,020 but we're outputting it now by the view 266 00:11:41,020 --> 00:11:42,560 in my local timezone time, 267 00:11:42,560 --> 00:11:44,790 so if you run this programme, you'll find that 268 00:11:44,790 --> 00:11:47,180 the time outputting will be in whatever timezone 269 00:11:47,180 --> 00:11:49,320 is configured on your computer. 270 00:11:49,320 --> 00:11:52,090 Just keep in mind to remember to refresh the history table 271 00:11:52,090 --> 00:11:55,070 in the database viewer to ensure that the two sets of data 272 00:11:55,070 --> 00:11:58,560 will tally, and they should certainly do that. 273 00:11:58,560 --> 00:12:01,170 Alright, so the dates have come back as strings, 274 00:12:01,170 --> 00:12:02,600 so if you want date time values, 275 00:12:02,600 --> 00:12:04,160 you'd have to parse the dates 276 00:12:04,160 --> 00:12:07,550 using the date classes strptime method, 277 00:12:07,550 --> 00:12:09,900 but because there's no timezone information, 278 00:12:09,900 --> 00:12:12,450 these string values can be successfully parsed 279 00:12:12,450 --> 00:12:17,010 into date time values using the strptime function, 280 00:12:17,010 --> 00:12:18,850 so that's two different approaches 281 00:12:18,850 --> 00:12:20,840 to retrieving the time stamps 282 00:12:20,840 --> 00:12:23,240 and displaying them in the user's local time. 283 00:12:23,240 --> 00:12:25,790 Each one has its advantages and disadvantages, 284 00:12:25,790 --> 00:12:27,600 so it's handy to have both methods 285 00:12:27,600 --> 00:12:29,690 in your arsenal of techniques. 286 00:12:29,690 --> 00:12:31,480 Now, I've demonstrated these techniques 287 00:12:31,480 --> 00:12:32,960 using our accounts class, 288 00:12:32,960 --> 00:12:35,520 but they can be used whenever you need to store time values 289 00:12:35,520 --> 00:12:37,560 in a SQLite database. 290 00:12:37,560 --> 00:12:39,690 One thing that neither approach lets us do 291 00:12:39,690 --> 00:12:41,800 is store the original timezone information 292 00:12:41,800 --> 00:12:43,000 in the database. 293 00:12:43,000 --> 00:12:45,440 As I mentioned, there are external libraries 294 00:12:45,440 --> 00:12:46,920 that can make this easier, 295 00:12:46,920 --> 00:12:48,990 but it is possible using standard Python 296 00:12:48,990 --> 00:12:51,090 and the pytz library, 297 00:12:51,090 --> 00:12:53,410 and we're gonna see how to do this in the next video, 298 00:12:53,410 --> 00:12:55,730 but I'm going to set it as a challenge. 299 00:12:55,730 --> 00:12:57,270 This challenge is gonna be optional. 300 00:12:57,270 --> 00:12:59,570 If you need to work with dates and times a lot, 301 00:12:59,570 --> 00:13:01,710 I do suggest giving it a go, 302 00:13:01,710 --> 00:13:03,370 and I'll provide some hints 303 00:13:03,370 --> 00:13:04,930 so that you don't waste a lot of time 304 00:13:04,930 --> 00:13:06,760 trying things that just won't work, 305 00:13:06,760 --> 00:13:09,140 but if you're not likely to use dates and times very often 306 00:13:09,140 --> 00:13:12,310 in your databases, then perhaps just skip to the solution 307 00:13:12,310 --> 00:13:14,720 so you know how to do it should you need to. 308 00:13:14,720 --> 00:13:17,840 Alright, so let's move onto that video now.