1 00:00:05,440 --> 00:00:07,100 So we ended the previous video with 2 00:00:07,100 --> 00:00:10,060 completing the challenge, but I also want 3 00:00:10,060 --> 00:00:11,670 to talk about something else 4 00:00:11,670 --> 00:00:14,480 just before we finish off and move on to the next thing. 5 00:00:14,480 --> 00:00:17,820 That is, if you do find that you need to store the 6 00:00:17,820 --> 00:00:21,180 original time zone info for a time, 7 00:00:21,180 --> 00:00:23,430 then either use an external library, 8 00:00:23,430 --> 00:00:25,160 but you can also do it like this, 9 00:00:25,160 --> 00:00:26,890 which we're about to show you. 10 00:00:26,890 --> 00:00:30,860 Definitely don't be tempted to store your localised times. 11 00:00:30,860 --> 00:00:33,760 Always work in UTC, then convert when you need 12 00:00:33,760 --> 00:00:36,890 to display or print the local times. 13 00:00:36,890 --> 00:00:39,530 So let's assume that we decide to just store ACTD 14 00:00:39,530 --> 00:00:43,570 in a column instead of pickling the TZ info object. 15 00:00:43,570 --> 00:00:45,140 We should then be able to create 16 00:00:45,140 --> 00:00:48,090 a new TZ info for that time zone. 17 00:00:48,090 --> 00:00:50,310 Let's actually have a go at doing that. 18 00:00:50,310 --> 00:00:52,450 I'm just going to comment these two lines out 19 00:00:52,450 --> 00:00:55,780 that pickles and score zone in the zone. 20 00:00:58,640 --> 00:00:59,650 Let's see whether we can do that. 21 00:00:59,650 --> 00:01:03,740 We're going to put zone is equal to PYTZ.timezone 22 00:01:06,640 --> 00:01:08,390 and let's put in CET. 23 00:01:09,260 --> 00:01:11,940 CET is Central European Time. 24 00:01:11,940 --> 00:01:13,840 Abbreviate it to CET. 25 00:01:13,840 --> 00:01:15,670 If we try running that 26 00:01:19,930 --> 00:01:23,000 you'll see that the times are showing as CET time, 27 00:01:23,000 --> 00:01:24,860 which is one hour ahead of Greenwich Mean Time 28 00:01:24,860 --> 00:01:26,800 this time of year. 29 00:01:26,800 --> 00:01:28,130 That works fine. 30 00:01:29,000 --> 00:01:30,110 You might be asking at this point, 31 00:01:30,110 --> 00:01:31,800 "Well, why didn't I just store the strings 32 00:01:31,800 --> 00:01:34,010 CET in the database?" 33 00:01:34,010 --> 00:01:35,380 Well, the reason for that is 34 00:01:35,380 --> 00:01:37,450 that the time zone info's name 35 00:01:37,450 --> 00:01:41,820 can't be reliably used to create a new time zone object. 36 00:01:41,820 --> 00:01:44,470 CET is now one of the few that can, 37 00:01:44,470 --> 00:01:47,150 which is why I've used it here as an example. 38 00:01:47,150 --> 00:01:49,650 If I change this back to ACDT, 39 00:01:53,900 --> 00:01:55,800 Australian Central Dialect Time, 40 00:01:55,800 --> 00:01:59,850 and run this you can see we actually get an error. 41 00:01:59,850 --> 00:02:03,290 There are a few flaws and omissions in the date time 42 00:02:03,290 --> 00:02:05,960 in PYTZ libraries, and unfortunately 43 00:02:05,960 --> 00:02:07,400 this is one of them. 44 00:02:07,400 --> 00:02:08,669 You know, I can make the programme work 45 00:02:08,669 --> 00:02:10,570 by changing the string, 46 00:02:10,570 --> 00:02:14,480 instead of ACDT, Australian Central Dialect Time, 47 00:02:14,480 --> 00:02:18,650 I can type in Australia slash Adelaide and run that. 48 00:02:22,020 --> 00:02:23,680 We can see that correctly there works, 49 00:02:23,680 --> 00:02:26,630 and we're getting the plus 10 30 again offset. 50 00:02:26,630 --> 00:02:27,850 What you actually get returned when 51 00:02:27,850 --> 00:02:30,430 the default time zone is used can vary, 52 00:02:30,430 --> 00:02:32,780 not just from one operating system to another 53 00:02:32,780 --> 00:02:34,020 but also on different versions of 54 00:02:34,020 --> 00:02:36,060 the same operating system. 55 00:02:36,060 --> 00:02:38,160 It would have been a nice solution, 56 00:02:38,160 --> 00:02:40,820 but unfortunately it won't work. 57 00:02:40,820 --> 00:02:42,390 You probably have found it 58 00:02:42,390 --> 00:02:44,440 very frustrating discovering that. 59 00:02:44,440 --> 00:02:46,200 Had you been in Central Europe, 60 00:02:46,200 --> 00:02:47,760 you wouldn't have discovered the problem 61 00:02:47,760 --> 00:02:49,420 unless you tested on a computer 62 00:02:49,420 --> 00:02:51,130 in a different time zone. 63 00:02:51,130 --> 00:02:53,460 If you'd chosen EST to test time, 64 00:02:53,460 --> 00:02:55,440 you still wouldn't have seen the problem 65 00:02:55,440 --> 00:02:59,610 because EST will work just as the CET time zone worked. 66 00:03:01,060 --> 00:03:02,420 Okay, so we've covered quite a lot 67 00:03:02,420 --> 00:03:04,830 since we created our accounts class. 68 00:03:04,830 --> 00:03:07,300 I've focused on dates and times a lot, 69 00:03:07,300 --> 00:03:08,740 but the techniques aren't just 70 00:03:08,740 --> 00:03:11,130 restricted to time information. 71 00:03:11,130 --> 00:03:13,130 For example, using SQL-like functions 72 00:03:13,130 --> 00:03:15,140 and queries is a great technique, 73 00:03:15,140 --> 00:03:16,320 and you'll find a list of 74 00:03:16,320 --> 00:03:18,430 the core functions on this page. 75 00:03:18,430 --> 00:03:21,510 I'll just bring that up in a browser. 76 00:03:25,640 --> 00:03:28,570 There's some good core functinos there for SQL Light. 77 00:03:28,570 --> 00:03:31,420 There's also this link here to date and time functions. 78 00:03:31,420 --> 00:03:33,510 We've seen that before, 79 00:03:33,510 --> 00:03:36,590 and also aggregate functions as well. 80 00:03:37,580 --> 00:03:39,790 It can be useful to check those out. 81 00:03:39,790 --> 00:03:41,690 I've also seen how to store a complete object 82 00:03:41,690 --> 00:03:44,170 in a database column by pickling it 83 00:03:44,170 --> 00:03:48,240 and that can be very handy where it's appropriate. 84 00:03:48,240 --> 00:03:50,520 Now, the antenna J database field makes life 85 00:03:50,520 --> 00:03:53,080 a lot easier when writing database code 86 00:03:53,080 --> 00:03:54,940 as you don't have to keep switching 87 00:03:54,940 --> 00:03:56,060 into a terminal to check the 88 00:03:56,060 --> 00:03:58,310 state of your database tables. 89 00:03:58,310 --> 00:04:00,140 We also had it to have a look at 90 00:04:00,140 --> 00:04:02,510 how to work with monetary amounts 91 00:04:02,510 --> 00:04:04,260 and financial applications so that 92 00:04:04,260 --> 00:04:06,100 we don't get strange rounding errors, 93 00:04:06,100 --> 00:04:07,540 which would be totally unacceptable 94 00:04:07,540 --> 00:04:09,230 in a financial programme. 95 00:04:09,230 --> 00:04:11,600 There have been a few digressions on our way 96 00:04:11,600 --> 00:04:13,350 to writing back transactions, 97 00:04:13,350 --> 00:04:15,160 but the examples that we're using 98 00:04:15,160 --> 00:04:18,370 are now more like real-world problems. 99 00:04:18,370 --> 00:04:20,790 Let's end the video here, and in the next one 100 00:04:20,790 --> 00:04:21,620 we'll finally get around to 101 00:04:21,620 --> 00:04:24,380 rolling back database transactions. 102 00:04:24,380 --> 00:04:26,430 See you in the next video.