WEBVTT 1 00:00:02.580 --> 00:00:03.625 Alright, in this video, 2 00:00:03.625 --> 00:00:05.454 we're gonna look at an alternative way 3 00:00:05.454 --> 00:00:07.758 to show the times in UTC times, 4 00:00:07.758 --> 00:00:10.241 and the other way of doing this is to use 5 00:00:10.241 --> 00:00:12.359 the SQLite date time functions 6 00:00:12.359 --> 00:00:14.791 and perform the conversion before actually getting 7 00:00:14.791 --> 00:00:17.072 the data back from the server, 8 00:00:17.072 --> 00:00:20.427 so I'm gonna change the query here in checkdb.py 9 00:00:20.427 --> 00:00:21.479 and then run the programme, 10 00:00:21.479 --> 00:00:23.164 and then we'll have a look at what's happening 11 00:00:23.164 --> 00:00:25.657 and refer to the SQLite documentation. 12 00:00:25.657 --> 00:00:28.012 So, we're no longer with this second example, 13 00:00:28.012 --> 00:00:31.708 need to import pytz, so I'm going to just delete that, 14 00:00:31.708 --> 00:00:33.796 and then we're gonna change the code. 15 00:00:33.796 --> 00:00:36.372 So, we're gonna start with the query, 16 00:00:36.372 --> 00:00:37.618 and the query's now going to be 17 00:00:37.618 --> 00:00:39.537 a little bit more complex than what it was before, 18 00:00:39.537 --> 00:00:40.575 so it's gonna be select, 19 00:00:40.575 --> 00:00:42.677 and I'll just delete this last part out. 20 00:00:42.677 --> 00:00:43.979 Type it again. 21 00:00:43.979 --> 00:00:48.146 SELECT strftime and then left print to say single quote, 22 00:00:49.343 --> 00:00:53.228 percent, capital Y, dash percent, lowercase m, 23 00:00:53.228 --> 00:00:55.978 dash percent, lowercase d, space, 24 00:00:57.175 --> 00:00:59.758 then percent, capital H, colon, 25 00:01:01.058 --> 00:01:03.598 percent, capital m, colon, 26 00:01:03.598 --> 00:01:05.432 percent, lowercase f, 27 00:01:05.432 --> 00:01:07.687 single quote, and then a semicolon, 28 00:01:07.687 --> 00:01:10.935 then a comma, then I'm gonna type history 29 00:01:10.935 --> 00:01:11.768 dot time, 30 00:01:14.893 --> 00:01:15.976 and localtime 31 00:01:18.372 --> 00:01:20.158 as localtime, 32 00:01:20.158 --> 00:01:24.075 comma, and then we'll go to the next line here. 33 00:01:25.227 --> 00:01:26.562 Then we're gonna do, then history. 34 00:01:26.562 --> 00:01:27.833 We're gonna space it at the start. 35 00:01:27.833 --> 00:01:31.123 History dot account, comma, space, 36 00:01:31.123 --> 00:01:32.706 history dot amount, 37 00:01:34.777 --> 00:01:35.860 from history, 38 00:01:38.203 --> 00:01:39.036 order by 39 00:01:40.848 --> 00:01:42.265 history dot time. 40 00:01:46.180 --> 00:01:47.977 And by the way, if you're getting this message 41 00:01:47.977 --> 00:01:51.005 popping up here, SQLite dialect is not configured, 42 00:01:51.005 --> 00:01:52.566 you can actually fix that easily enough. 43 00:01:52.566 --> 00:01:54.550 You can go into preferences or setup, 44 00:01:54.550 --> 00:01:57.467 depending on your operating system, 45 00:01:58.560 --> 00:02:01.143 and if you do a search for SQL, 46 00:02:02.291 --> 00:02:04.072 you should find SQL Dialects comes up. 47 00:02:04.072 --> 00:02:06.979 I click on that, and what we need to do is 48 00:02:06.979 --> 00:02:08.311 look at our particular files. 49 00:02:08.311 --> 00:02:09.983 In this case, checkdb. 50 00:02:09.983 --> 00:02:11.738 I come over here and click on that, 51 00:02:11.738 --> 00:02:14.433 and I can choose SQLite, so being specific, 52 00:02:14.433 --> 00:02:17.689 turning it to the dialect of SQL that we're gonna be using, 53 00:02:17.689 --> 00:02:19.146 and click OK. 54 00:02:19.146 --> 00:02:23.372 Once we do that, that warning disappears now, 55 00:02:23.372 --> 00:02:25.056 and then all we need to do now is 56 00:02:25.056 --> 00:02:26.977 I'm going to delete all of that, 57 00:02:26.977 --> 00:02:29.183 and then we're gonna just replace that, 58 00:02:29.183 --> 00:02:32.399 pretty simply, with print row, 59 00:02:32.399 --> 00:02:34.831 and we'll leave the db.close there. 60 00:02:34.831 --> 00:02:36.650 So let's actually just try running that 61 00:02:36.650 --> 00:02:38.931 to see whether it works, 62 00:02:38.931 --> 00:02:40.964 and you can see here, in this case, 63 00:02:40.964 --> 00:02:42.833 we get the dates back in my local time, 64 00:02:42.833 --> 00:02:44.880 or we've got SQLite, rather, 65 00:02:44.880 --> 00:02:47.126 to do the work for us. 66 00:02:47.126 --> 00:02:49.242 So this method has the advantage 67 00:02:49.242 --> 00:02:51.969 that it's gonna work whichever client is being used 68 00:02:51.969 --> 00:02:53.492 to access the database, 69 00:02:53.492 --> 00:02:56.148 so we could create a view with that select statement, 70 00:02:56.148 --> 00:02:58.083 and the data would be available to users 71 00:02:58.083 --> 00:03:00.551 in their local time, and you could use the view 72 00:03:00.551 --> 00:03:03.181 from the SQLite command line interface, for example, 73 00:03:03.181 --> 00:03:04.826 and get the same result. 74 00:03:04.826 --> 00:03:07.369 Now, we're gonna create creative view in a minute, 75 00:03:07.369 --> 00:03:10.599 but first, let's just have a look at what we've done. 76 00:03:10.599 --> 00:03:14.851 So, the select query uses the SQLite's strftime function, 77 00:03:14.851 --> 00:03:17.207 this one up here on line six, 78 00:03:17.207 --> 00:03:20.244 to convert the time field into a string. 79 00:03:20.244 --> 00:03:22.716 Now, we've seen how to use functions, such as count, 80 00:03:22.716 --> 00:03:24.089 earlier in this section, 81 00:03:24.089 --> 00:03:26.541 so here, we're just using a different function. 82 00:03:26.541 --> 00:03:29.924 Now, the first parameter to string f time 83 00:03:29.924 --> 00:03:34.177 is a format string, which determines the format 84 00:03:34.177 --> 00:03:37.319 for the date and time string that'll ultimately be produced, 85 00:03:37.319 --> 00:03:41.486 so next we provide a time value here in history.time, 86 00:03:42.518 --> 00:03:44.019 so we're getting that from the time column 87 00:03:44.019 --> 00:03:45.382 on the history table. 88 00:03:45.382 --> 00:03:49.370 We then provide a modifier, localtime in this case, 89 00:03:49.370 --> 00:03:51.444 and over here is the third argument, 90 00:03:51.444 --> 00:03:55.754 to cause the UTC time to be converted to local time. 91 00:03:55.754 --> 00:03:58.572 Now, the SQLite date time functions 92 00:03:58.572 --> 00:04:00.217 are documented quite well, 93 00:04:00.217 --> 00:04:01.551 so we just open that up. 94 00:04:01.551 --> 00:04:05.306 Gonna browse up, and the link is in the resources section. 95 00:04:05.306 --> 00:04:08.570 You can check that out at your leisure, 96 00:04:08.570 --> 00:04:12.036 and you can see strftime is there, 97 00:04:12.036 --> 00:04:14.536 so we do a search for that one 98 00:04:18.998 --> 00:04:20.816 and find out more information about it, 99 00:04:20.816 --> 00:04:22.972 or we can actually click on 100 00:04:22.972 --> 00:04:26.438 and see that it's based on the C version of the 101 00:04:26.438 --> 00:04:29.158 function of the same name. 102 00:04:29.158 --> 00:04:31.775 And the documentation states that 103 00:04:31.775 --> 00:04:33.697 there are five date and time functions, 104 00:04:33.697 --> 00:04:36.250 and obviously we've used the string f time. 105 00:04:36.250 --> 00:04:38.083 Now, that's strictly the only one that's necessary, 106 00:04:38.083 --> 00:04:39.930 the string f time, because all the others 107 00:04:39.930 --> 00:04:42.339 can be expressed using that one. 108 00:04:42.339 --> 00:04:44.908 The other functions are really just provided for convenience 109 00:04:44.908 --> 00:04:47.175 so that you don't have to mess around with format strings. 110 00:04:47.175 --> 00:04:49.356 Now, they may also be more efficient, 111 00:04:49.356 --> 00:04:53.047 because strftime is a more generic function. 112 00:04:53.047 --> 00:04:55.391 It has to pass the format string, for example, 113 00:04:55.391 --> 00:04:58.183 which makes it less efficient than the other methods, 114 00:04:58.183 --> 00:04:59.929 so you might be asking, at this point, 115 00:04:59.929 --> 00:05:02.646 why have I used string f time, or strftime, 116 00:05:02.646 --> 00:05:05.129 instead of datetime? 117 00:05:05.129 --> 00:05:07.633 I'll leave you to have a go at changing the query 118 00:05:07.633 --> 00:05:09.588 to use the datetime function instead. 119 00:05:09.588 --> 00:05:11.709 Just remember to remove the format string 120 00:05:11.709 --> 00:05:15.372 and refer to this documentation for the parameters. 121 00:05:15.372 --> 00:05:16.758 Now, when you get it working, 122 00:05:16.758 --> 00:05:19.238 notice that the seconds are displayed as whole seconds, 123 00:05:19.238 --> 00:05:22.637 with no fractional part, so it doesn't round either. 124 00:05:22.637 --> 00:05:26.252 It just truncates the fractional part. 125 00:05:26.252 --> 00:05:28.579 Now, in some applications, that'll be fine, 126 00:05:28.579 --> 00:05:29.761 but in our application, 127 00:05:29.761 --> 00:05:32.244 we need millisecond accuracy to ensure the transactions, 128 00:05:32.244 --> 00:05:36.233 or that transactions appear in the correct order. 129 00:05:36.233 --> 00:05:39.549 Now, in fact, the sharp eyed amongst you may have noticed 130 00:05:39.549 --> 00:05:41.281 that the SQLite function doesn't provide 131 00:05:41.281 --> 00:05:43.860 the same level of accuracy as the Python method. 132 00:05:43.860 --> 00:05:46.218 We'll just go back to the code now. 133 00:05:46.218 --> 00:05:48.849 The database is storing six decimals for the seconds, 134 00:05:48.849 --> 00:05:50.956 and we'll just confirm that. 135 00:05:50.956 --> 00:05:52.877 One two three four five six, 136 00:05:52.877 --> 00:05:54.797 after the dot 32, 137 00:05:54.797 --> 00:05:56.378 but in terms of our output, 138 00:05:56.378 --> 00:05:59.572 from the checkdb code that we've created, 139 00:05:59.572 --> 00:06:01.756 we're only seeing three decimal points. 140 00:06:01.756 --> 00:06:04.310 In other words, the SQLite date functions only work 141 00:06:04.310 --> 00:06:05.805 to three decimal places. 142 00:06:05.805 --> 00:06:08.089 Now, this is mentioned in the documentation. 143 00:06:08.089 --> 00:06:10.671 I won't go back to it now, but it's under the last paragraph 144 00:06:10.671 --> 00:06:12.775 in the time string section, 145 00:06:12.775 --> 00:06:15.318 and that's why I ordered our query by the time field, 146 00:06:15.318 --> 00:06:18.247 rather than from our calculated local field, 147 00:06:18.247 --> 00:06:20.692 so here, order by history.time 148 00:06:20.692 --> 00:06:24.282 instead of doing it with our calculated field here, 149 00:06:24.282 --> 00:06:25.453 which was localtime. 150 00:06:25.453 --> 00:06:27.111 That way, we're still getting the benefit 151 00:06:27.111 --> 00:06:30.365 of the six decimal points of precision. 152 00:06:30.365 --> 00:06:32.611 Now, the SQLite date functions only work, 153 00:06:32.611 --> 00:06:34.429 as you can see, to three decimal points. 154 00:06:34.429 --> 00:06:36.314 Now, this is mentioned in the documentation, 155 00:06:36.314 --> 00:06:39.343 which I will zip back to quickly, 156 00:06:39.343 --> 00:06:42.364 and it's under time strings, 157 00:06:42.364 --> 00:06:43.197 down here. 158 00:06:47.473 --> 00:06:49.401 So that's actually why I ordered our query 159 00:06:49.401 --> 00:06:51.771 by the time field, rather than from our 160 00:06:51.771 --> 00:06:53.608 calculated local time field, 161 00:06:53.608 --> 00:06:55.689 so just to show you what I mean. 162 00:06:55.689 --> 00:06:58.838 Say the SQLite order by clause on the line seven here 163 00:06:58.838 --> 00:07:01.106 is still using the history dot time field 164 00:07:01.106 --> 00:07:02.842 directly from the database, 165 00:07:02.842 --> 00:07:05.794 and we're not trying to order by this localtime, 166 00:07:05.794 --> 00:07:07.881 so as a result, we're still getting the time 167 00:07:07.881 --> 00:07:09.732 in the six decimal places instead of three, 168 00:07:09.732 --> 00:07:11.597 so it's more accurate. 169 00:07:11.597 --> 00:07:13.709 And just to confirm, if we open the history table, 170 00:07:13.709 --> 00:07:15.656 you can see that that is six decimal points 171 00:07:15.656 --> 00:07:18.511 of precision there, compared to the three that our output 172 00:07:18.511 --> 00:07:22.678 by the checkdb programme using this strftime function. 173 00:07:24.703 --> 00:07:26.747 I'll just go back to the documentation again, 174 00:07:26.747 --> 00:07:28.604 and just before we actually finish with it, 175 00:07:28.604 --> 00:07:31.547 the SQLite strftime function's format string 176 00:07:31.547 --> 00:07:34.578 behaves slightly differently to Python's, 177 00:07:34.578 --> 00:07:37.670 and it's quite actually hard to spot from the documentation, 178 00:07:37.670 --> 00:07:40.670 but if we do a search for percent f, 179 00:07:44.251 --> 00:07:45.810 see here, under fractional seconds, 180 00:07:45.810 --> 00:07:47.497 SS dot SSS, 181 00:07:47.497 --> 00:07:49.489 notice that it includes SS 182 00:07:49.489 --> 00:07:50.905 to the left of the decimal point, 183 00:07:50.905 --> 00:07:54.220 so percent f, when using the strftime function, 184 00:07:54.220 --> 00:07:57.976 will give you seconds and their fractional part. 185 00:07:57.976 --> 00:08:01.378 Now, if you use the Python strp time function, 186 00:08:01.378 --> 00:08:04.784 the percent f will only give you the fractional part. 187 00:08:04.784 --> 00:08:06.402 So in other words, in Python, 188 00:08:06.402 --> 00:08:08.928 we would need to use a percent capital S, 189 00:08:08.928 --> 00:08:12.771 dot percent f to get the full seconds value. 190 00:08:12.771 --> 00:08:14.992 Now, I mentioned earlier that it's important 191 00:08:14.992 --> 00:08:17.212 to refer to the correct set of documentation, 192 00:08:17.212 --> 00:08:18.771 and if you're using Python functions, 193 00:08:18.771 --> 00:08:22.722 make sure you use the Python SQLite3 library documentation, 194 00:08:22.722 --> 00:08:27.150 and when working with SQLite, use the SQLite documentation. 195 00:08:27.150 --> 00:08:28.875 Alright, so let's go back now to our code 196 00:08:28.875 --> 00:08:31.723 and create a view for this query, 197 00:08:31.723 --> 00:08:34.403 so we're gonna go back to rollback.py, 198 00:08:34.403 --> 00:08:38.165 and a place for adding the view is obviously there, 199 00:08:38.165 --> 00:08:40.489 because that's where we're creating the tables, 200 00:08:40.489 --> 00:08:42.434 so I'm gonna go back and copy all the text 201 00:08:42.434 --> 00:08:44.665 from db.execute onwards 202 00:08:44.665 --> 00:08:47.285 and paste it into rollback.py. 203 00:08:47.285 --> 00:08:49.834 Let's go back and do that, 204 00:08:49.834 --> 00:08:54.124 so I'm just gonna do db.execute and copy that, 205 00:08:54.124 --> 00:08:56.175 and go back to rollback.py. 206 00:08:56.175 --> 00:09:00.160 We're gonna put that below the two table creations 207 00:09:00.160 --> 00:09:03.160 and get rid of the colon on the end. 208 00:09:04.949 --> 00:09:07.279 So, now what we need to do is change that a little bit 209 00:09:07.279 --> 00:09:10.299 to create a view, rather than executing query, 210 00:09:10.299 --> 00:09:12.003 so I'm gonna add this at the start, 211 00:09:12.003 --> 00:09:15.753 instead of select, we're gonna do create view 212 00:09:17.068 --> 00:09:18.235 if not exists, 213 00:09:20.722 --> 00:09:22.055 localhistory as, 214 00:09:24.099 --> 00:09:26.368 and leave the rest of the lines in there, 215 00:09:26.368 --> 00:09:29.283 and we got a warning here about the line being too long, 216 00:09:29.283 --> 00:09:32.428 so I'm just going to split it there. 217 00:09:32.428 --> 00:09:35.181 And just to be complete, we need to put a space there 218 00:09:35.181 --> 00:09:37.426 to keep everything happy and make sure that 219 00:09:37.426 --> 00:09:41.243 we've got a relevant space so that the SQL code still works, 220 00:09:41.243 --> 00:09:43.801 and we'll also modify the connexion now, 221 00:09:43.801 --> 00:09:45.580 accounts dot sqlite. 222 00:09:45.580 --> 00:09:48.248 Let's also do that detect underscore types 223 00:09:48.248 --> 00:09:52.415 is equal to sqlite dot PARSE underscore DECLTYPES, 224 00:09:53.385 --> 00:09:54.832 which we talked about, 225 00:09:54.832 --> 00:09:56.714 and when we do that, we get this warning, 226 00:09:56.714 --> 00:09:58.952 which we can see over here, 227 00:09:58.952 --> 00:10:02.036 and we can fix that warning up if we want to 228 00:10:02.036 --> 00:10:04.828 by just going again into our preferences or settings, 229 00:10:04.828 --> 00:10:08.457 doing a search for SQL and go to SQL Dialects, 230 00:10:08.457 --> 00:10:10.224 and then we can select the file. 231 00:10:10.224 --> 00:10:12.895 In this case, rollback, and change that to SQLite too, 232 00:10:12.895 --> 00:10:14.753 just if you wanna get rid of the warning. 233 00:10:14.753 --> 00:10:16.065 It'll work without it, 234 00:10:16.065 --> 00:10:18.844 but it looks a bit nicer without any warnings. 235 00:10:18.844 --> 00:10:21.375 Alright, so let's clear the history table again. 236 00:10:21.375 --> 00:10:23.868 I'm going to select all four, 237 00:10:23.868 --> 00:10:26.718 delete them, and then save it. 238 00:10:26.718 --> 00:10:29.789 Obviously, we've got an empty history table there now. 239 00:10:29.789 --> 00:10:32.566 Alright, and we're going to run this 240 00:10:32.566 --> 00:10:35.238 so the view gets created. 241 00:10:35.238 --> 00:10:37.648 No errors, which is good, 242 00:10:37.648 --> 00:10:39.251 and if you go back now to checkdb, 243 00:10:39.251 --> 00:10:41.110 we can change the code from there, 244 00:10:41.110 --> 00:10:43.408 and let's do that and use the query, 245 00:10:43.408 --> 00:10:46.718 so I'm just gonna comment that code out. 246 00:10:46.718 --> 00:10:48.027 We've got a reference tool, 247 00:10:48.027 --> 00:10:52.110 and then we'll put instead for row in db.execute, 248 00:10:53.436 --> 00:10:57.838 and it's gonna be now SELECT star from localhistory 249 00:10:57.838 --> 00:11:00.352 being the name of our view. 250 00:11:00.352 --> 00:11:02.814 We should be able to run that now, 251 00:11:02.814 --> 00:11:04.659 with the same results. 252 00:11:04.659 --> 00:11:06.656 You can see, we've got the results now, 253 00:11:06.656 --> 00:11:08.460 and obviously it's been updated, 254 00:11:08.460 --> 00:11:10.288 'cause I'm running this at a later point 255 00:11:10.288 --> 00:11:12.126 in my local time. 256 00:11:12.126 --> 00:11:14.745 Now, we can go back to history and we can go to refresh. 257 00:11:14.745 --> 00:11:16.827 There's our entries, 258 00:11:16.827 --> 00:11:19.266 and again, you can see the six points of precision there, 259 00:11:19.266 --> 00:11:21.491 compared to three decimal points of precision 260 00:11:21.491 --> 00:11:22.658 from using the 261 00:11:23.992 --> 00:11:25.159 string f time, 262 00:11:27.020 --> 00:11:30.735 the strftime function, which is part of SQLite. 263 00:11:30.735 --> 00:11:32.665 So, again, we're still storing it, 264 00:11:32.665 --> 00:11:35.520 and you have the history table in UTC time, 265 00:11:35.520 --> 00:11:38.069 but we're outputting it now by the view 266 00:11:38.069 --> 00:11:39.600 in my local timezone time, 267 00:11:39.600 --> 00:11:41.834 so if you run this programme, you'll find that 268 00:11:41.834 --> 00:11:44.226 the time outputting will be in whatever timezone 269 00:11:44.226 --> 00:11:46.368 is configured on your computer. 270 00:11:46.368 --> 00:11:49.139 Just keep in mind to remember to refresh the history table 271 00:11:49.139 --> 00:11:52.119 in the database viewer to ensure that the two sets of data 272 00:11:52.119 --> 00:11:55.609 will tally, and they should certainly do that. 273 00:11:55.609 --> 00:11:58.214 Alright, so the dates have come back as strings, 274 00:11:58.214 --> 00:11:59.647 so if you want date time values, 275 00:11:59.647 --> 00:12:01.206 you'd have to parse the dates 276 00:12:01.206 --> 00:12:04.592 using the date classes strptime method, 277 00:12:04.592 --> 00:12:06.940 but because there's no timezone information, 278 00:12:06.940 --> 00:12:09.491 these string values can be successfully parsed 279 00:12:09.491 --> 00:12:14.050 into date time values using the strptime function, 280 00:12:14.050 --> 00:12:15.891 so that's two different approaches 281 00:12:15.891 --> 00:12:17.886 to retrieving the time stamps 282 00:12:17.886 --> 00:12:20.288 and displaying them in the user's local time. 283 00:12:20.288 --> 00:12:22.838 Each one has its advantages and disadvantages, 284 00:12:22.838 --> 00:12:24.645 so it's handy to have both methods 285 00:12:24.645 --> 00:12:26.739 in your arsenal of techniques. 286 00:12:26.739 --> 00:12:28.521 Now, I've demonstrated these techniques 287 00:12:28.521 --> 00:12:30.003 using our accounts class, 288 00:12:30.003 --> 00:12:32.563 but they can be used whenever you need to store time values 289 00:12:32.563 --> 00:12:34.604 in a SQLite database. 290 00:12:34.604 --> 00:12:36.736 One thing that neither approach lets us do 291 00:12:36.736 --> 00:12:38.848 is store the original timezone information 292 00:12:38.848 --> 00:12:40.041 in the database. 293 00:12:40.041 --> 00:12:42.488 As I mentioned, there are external libraries 294 00:12:42.488 --> 00:12:43.968 that can make this easier, 295 00:12:43.968 --> 00:12:46.036 but it is possible using standard Python 296 00:12:46.036 --> 00:12:48.138 and the pytz library, 297 00:12:48.138 --> 00:12:50.450 and we're gonna see how to do this in the next video, 298 00:12:50.450 --> 00:12:52.771 but I'm going to set it as a challenge. 299 00:12:52.771 --> 00:12:54.315 This challenge is gonna be optional. 300 00:12:54.315 --> 00:12:56.613 If you need to work with dates and times a lot, 301 00:12:56.613 --> 00:12:58.753 I do suggest giving it a go, 302 00:12:58.753 --> 00:13:00.412 and I'll provide some hints 303 00:13:00.412 --> 00:13:01.976 so that you don't waste a lot of time 304 00:13:01.976 --> 00:13:03.808 trying things that just won't work, 305 00:13:03.808 --> 00:13:06.184 but if you're not likely to use dates and times very often 306 00:13:06.184 --> 00:13:09.350 in your databases, then perhaps just skip to the solution 307 00:13:09.350 --> 00:13:11.760 so you know how to do it should you need to. 308 00:13:11.760 --> 00:13:14.884 Alright, so let's move onto that video now.