WEBVTT 1 00:00:02.452 --> 00:00:04.114 So we ended the previous video with 2 00:00:04.114 --> 00:00:07.078 completing the challenge, but I also want 3 00:00:07.078 --> 00:00:08.683 to talk about something else 4 00:00:08.683 --> 00:00:11.493 just before we finish off and move on to the next thing. 5 00:00:11.493 --> 00:00:14.834 That is, if you do find that you need to store the 6 00:00:14.834 --> 00:00:18.199 original time zone info for a time, 7 00:00:18.199 --> 00:00:20.442 then either use an external library, 8 00:00:20.442 --> 00:00:22.179 but you can also do it like this, 9 00:00:22.179 --> 00:00:23.909 which we're about to show you. 10 00:00:23.909 --> 00:00:27.873 Definitely don't be tempted to store your localised times. 11 00:00:27.873 --> 00:00:30.771 Always work in UTC, then convert when you need 12 00:00:30.771 --> 00:00:33.901 to display or print the local times. 13 00:00:33.901 --> 00:00:36.544 So let's assume that we decide to just store ACTD 14 00:00:36.544 --> 00:00:40.588 in a column instead of pickling the TZ info object. 15 00:00:40.588 --> 00:00:42.154 We should then be able to create 16 00:00:42.154 --> 00:00:45.103 a new TZ info for that time zone. 17 00:00:45.103 --> 00:00:47.326 Let's actually have a go at doing that. 18 00:00:47.326 --> 00:00:49.463 I'm just going to comment these two lines out 19 00:00:49.463 --> 00:00:52.796 that pickles and score zone in the zone. 20 00:00:55.658 --> 00:00:56.669 Let's see whether we can do that. 21 00:00:56.669 --> 00:01:00.752 We're going to put zone is equal to PYTZ.timezone 22 00:01:03.653 --> 00:01:05.403 and let's put in CET. 23 00:01:06.279 --> 00:01:08.952 CET is Central European Time. 24 00:01:08.952 --> 00:01:10.852 Abbreviate it to CET. 25 00:01:10.852 --> 00:01:12.685 If we try running that 26 00:01:16.945 --> 00:01:20.010 you'll see that the times are showing as CET time, 27 00:01:20.010 --> 00:01:21.879 which is one hour ahead of Greenwich Mean Time 28 00:01:21.879 --> 00:01:23.812 this time of year. 29 00:01:23.812 --> 00:01:25.145 That works fine. 30 00:01:26.010 --> 00:01:27.122 You might be asking at this point, 31 00:01:27.122 --> 00:01:28.819 "Well, why didn't I just store the strings 32 00:01:28.819 --> 00:01:31.020 CET in the database?" 33 00:01:31.020 --> 00:01:32.395 Well, the reason for that is 34 00:01:32.395 --> 00:01:34.469 that the time zone info's name 35 00:01:34.469 --> 00:01:38.839 can't be reliably used to create a new time zone object. 36 00:01:38.839 --> 00:01:41.485 CET is now one of the few that can, 37 00:01:41.485 --> 00:01:44.163 which is why I've used it here as an example. 38 00:01:44.163 --> 00:01:46.663 If I change this back to ACDT, 39 00:01:50.916 --> 00:01:52.812 Australian Central Dialect Time, 40 00:01:52.812 --> 00:01:56.869 and run this you can see we actually get an error. 41 00:01:56.869 --> 00:02:00.309 There are a few flaws and omissions in the date time 42 00:02:00.309 --> 00:02:02.975 in PYTZ libraries, and unfortunately 43 00:02:02.975 --> 00:02:04.415 this is one of them. 44 00:02:04.415 --> 00:02:05.687 You know, I can make the programme work 45 00:02:05.687 --> 00:02:07.581 by changing the string, 46 00:02:07.581 --> 00:02:11.495 instead of ACDT, Australian Central Dialect Time, 47 00:02:11.495 --> 00:02:15.662 I can type in Australia slash Adelaide and run that. 48 00:02:19.032 --> 00:02:20.697 We can see that correctly there works, 49 00:02:20.697 --> 00:02:23.649 and we're getting the plus 10 30 again offset. 50 00:02:23.649 --> 00:02:24.861 What you actually get returned when 51 00:02:24.861 --> 00:02:27.442 the default time zone is used can vary, 52 00:02:27.442 --> 00:02:29.796 not just from one operating system to another 53 00:02:29.796 --> 00:02:31.038 but also on different versions of 54 00:02:31.038 --> 00:02:33.074 the same operating system. 55 00:02:33.074 --> 00:02:35.177 It would have been a nice solution, 56 00:02:35.177 --> 00:02:37.839 but unfortunately it won't work. 57 00:02:37.839 --> 00:02:39.405 You probably have found it 58 00:02:39.405 --> 00:02:41.455 very frustrating discovering that. 59 00:02:41.455 --> 00:02:43.216 Had you been in Central Europe, 60 00:02:43.216 --> 00:02:44.772 you wouldn't have discovered the problem 61 00:02:44.772 --> 00:02:46.431 unless you tested on a computer 62 00:02:46.431 --> 00:02:48.141 in a different time zone. 63 00:02:48.141 --> 00:02:50.476 If you'd chosen EST to test time, 64 00:02:50.476 --> 00:02:52.456 you still wouldn't have seen the problem 65 00:02:52.456 --> 00:02:56.623 because EST will work just as the CET time zone worked. 66 00:02:58.070 --> 00:02:59.439 Okay, so we've covered quite a lot 67 00:02:59.439 --> 00:03:01.840 since we created our accounts class. 68 00:03:01.840 --> 00:03:04.315 I've focused on dates and times a lot, 69 00:03:04.315 --> 00:03:05.752 but the techniques aren't just 70 00:03:05.752 --> 00:03:08.148 restricted to time information. 71 00:03:08.148 --> 00:03:10.142 For example, using SQL-like functions 72 00:03:10.142 --> 00:03:12.150 and queries is a great technique, 73 00:03:12.150 --> 00:03:13.336 and you'll find a list of 74 00:03:13.336 --> 00:03:15.443 the core functions on this page. 75 00:03:15.443 --> 00:03:18.526 I'll just bring that up in a browser. 76 00:03:22.653 --> 00:03:25.588 There's some good core functinos there for SQL Light. 77 00:03:25.588 --> 00:03:28.432 There's also this link here to date and time functions. 78 00:03:28.432 --> 00:03:30.521 We've seen that before, 79 00:03:30.521 --> 00:03:33.604 and also aggregate functions as well. 80 00:03:34.592 --> 00:03:36.804 It can be useful to check those out. 81 00:03:36.804 --> 00:03:38.703 I've also seen how to store a complete object 82 00:03:38.703 --> 00:03:41.182 in a database column by pickling it 83 00:03:41.182 --> 00:03:45.252 and that can be very handy where it's appropriate. 84 00:03:45.252 --> 00:03:47.533 Now, the antenna J database field makes life 85 00:03:47.533 --> 00:03:50.099 a lot easier when writing database code 86 00:03:50.099 --> 00:03:51.958 as you don't have to keep switching 87 00:03:51.958 --> 00:03:53.074 into a terminal to check the 88 00:03:53.074 --> 00:03:55.320 state of your database tables. 89 00:03:55.320 --> 00:03:57.151 We also had it to have a look at 90 00:03:57.151 --> 00:03:59.527 how to work with monetary amounts 91 00:03:59.527 --> 00:04:01.273 and financial applications so that 92 00:04:01.273 --> 00:04:03.119 we don't get strange rounding errors, 93 00:04:03.119 --> 00:04:04.558 which would be totally unacceptable 94 00:04:04.558 --> 00:04:06.243 in a financial programme. 95 00:04:06.243 --> 00:04:08.619 There have been a few digressions on our way 96 00:04:08.619 --> 00:04:10.366 to writing back transactions, 97 00:04:10.366 --> 00:04:12.172 but the examples that we're using 98 00:04:12.172 --> 00:04:15.387 are now more like real-world problems. 99 00:04:15.387 --> 00:04:17.803 Let's end the video here, and in the next one 100 00:04:17.803 --> 00:04:18.636 we'll finally get around to 101 00:04:18.636 --> 00:04:21.392 rolling back database transactions. 102 00:04:21.392 --> 00:04:23.449 See you in the next video.