It's about time

Speaker 1: Now, next up our last talk aptly titled It's about time is by Russell. We've seen a lot of Russell already on the stage, which is a good thing because he has graciously agreed to run the lightning talks on day one and two. masterfully. Very great. Thank you, Russ. And now Russell, who is a veteran member of the Django core team, I think twelve years. wasn't it? Uh and is very very involved with Python and Django especially is going to tell us why handling time and time zones is so very very very complex and painful. Thank you.

Speaker 2: Well, good afternoon. As Tabir said, uh I'm Russell Keith McGee. I come from Wadjuknunga country, otherwise known as Perth, Western Australia. Uh you may know me from my work as an ambassador for WASPCON and my work on conference catering. In my day job, I am a senior data engineer at Savata. We're a market research company. We use Python and data science to help brands to understand their customers. They help me to get to conferences like DjangoCon, for which I am very much thankful. But I am better known because of my involvement in the Django community. I've been a member of the Django Core team for uh just over twelve years I was president of the Django Software Foundation from 2010 to 2015 and I served on the Django Technical Review Board for the 1. 7 through 1. 11 releases. More recently, I've been doing most of my open source contribution work on the BWAR project.

Speaker 2: BWARE is trying to bring Python to modern computing platforms like phones and tablets. The aim is to make using Python as simple for developing native applications as Django makes web development. Something that's accessible to newcomers but powerful enough for real heavy lifting. But no matter how simple Django makes web programming or BWARE makers makes mobile programming, there are some problems that are just capital H hard. And one of the big ones is dates and time Something you might not know about me, I am actually a horology nut. I love clocks and watches, and how that happened is an interesting and conveniently topical story. My undergraduate university degree is in physics. I went to university intending to do as much computing as I could, so I picked up some first-year computer programming units as electives.

Speaker 2: Now at this point I had been programming for years, so classes covering if statements and while loops really wasn't that much of a technical challenge. But the time came for our first mid-semester assignment and one of the requirements Write a program that will ask the user for a date and return whether it's a leap year and how many days will be in that year. Now, that was meant to be a prompt to do a bunch of keyboard inputs, convert a string to an integer, take modulo four, use an if statement. But I decided I wasn't going to do the obvious thing. I was going to show off a bit and build the best darn calendar utility the world had ever seen, which started me on a little bit of a journey. Because when you dig into it, it's not as simple as just mod four. The solar year, the amount of time it takes for the sun to orbit the Earth when you measure from equinox to equinox is something like 365.

Speaker 2: 24219 days So in addition to a leap year every four years, we make a special case every hundred years and don't add the leap day in February, and then every 400 years we make a special case of the special case and we do add the leap day. Where did these rules come from? Well, they're actually called the Gregorian calendar, because they were adopted by Pope Gregory XIII in a papal bull named Intergravissimus in October of 1582. Why did they adopt such a complex set of rules? Well, because the year was shifting. Prior to 1582, the Western Roman Catholic world used what was called the Julian calendar. The Julian calendar was adopted by Julius Caesar in 45 BC, but it only had the four-year leap year rule, and so every 128 years it gets a day ahead of the solar

Speaker 2: year. And as a result, by the 1500s, the solar year was ten days out of alignment with the calendar year. So that meant that the vernal equinox, the date in northern spring when the day and night are the same length, it didn't happen on March 20th, but on April 1st. So what? Well, it's a problem when one of your major religious holidays is observed relative to the vernal equinox. The date of Easter, technically, is the first Sunday after the first ecclesiastical full moon falling on or after the vernal equinox. So, if the date of the vernal equinox is shifting relative to the solar year, there's a problem. The problem of calculating the date of Easter is known as known technically as computus from the Latin word for computation, and it was the major problem that was addressed by astronomy and mathematics between the age of Aristotle and the Renaissance.

Speaker 2: The process of adopting the Gregorian calendar has some pretty hilarious consequences. Pop quiz. This is the 100th anniversary of Red October, the start of the 1918 Russian Revolution. What month did it start in? If you said October, you'd be wrong, because Imperial Russia, as part of the Eastern Orthodoxy, didn't adopt the Roman Catholic Gregorian calendar until after the Revolution. So when the October Revolution happened on October twenty-fifth, that was on the Julian calendar, but it was November seventh in Western Europe on the Gregorian calendar The Roman Catholic world made the calendar adjustment in October of 1582, so that year October only had 20 days. But only in the Roman Catholic world

Speaker 2: Sweden changed in 1700, but got the math wrong, overcompensated by a day, and so in 1712 they adjusted again, resulting in the one and only example of February 30th. The British Empire The British Empire changed in 1752, the Turkey didn't change until 1926. And so the number of days in the year and the number of days in February and even the number of days in October can vary depending upon what year you're evaluating and where you are in the world. So, that's where my interest in dates and times started. Let's just say that my first year computer science assignment was comprehensive.

Speaker 2: And Liz Murphy, my first year computer science lecturer, was a very, very patient woman. Now I didn't just tell this story for amusement value. It is amusing. But I did want to make a point. Like a lot of problems in computer science, something that seems relatively simple, like what is your name? What is your sex How many days are there this year can seem really simple on the surface and trivially easy to implement. But in practice, you actually need to understand a lot of human history if you're going to implement a robust solution. But they are solvable problems. These edge cases exist for reasons and there is logic behind them. And frankly the logic and the reasons are fascinating. You just have to be aware that there are edge cases and pay attention to them.

Speaker 2: For example, once you start to realize that there are different types of years, you can understand why most non-Christian holidays change date from year to year. They're not changing date, they're based on a different calendar. Judaism operates on what's called a lunisolar calendar. Its calendar, it's a calendar based on the phases of the moon. The Jewish calendar adds an extra month on the second or every second or third year to adjust for the procession between the lunar and the solar year. Islam operates on an astronomical lunar calendar, so the Islamic year is 10 to 11 days shorter than the solar year, and the date of Ramadan processes relative to the Gregorian calendar by 10 or 11 days every year. China, Japan, Korea, Vietnam, Mongolia, Nepal, many others, particularly in Asia, also operate their calendars on a lunar basis, which is why the date of the Lunar New Year, Chinese New Year,

Speaker 2: varies every year. And helpfully, Google had provided a demonstration for us just this week. Sitting in this room, jumping on Google and search for date, on some devices, like mine, it told you the year was 2651, uh 2561. Which it is in Thailand. On the Thai Buddhist calendar, which is Lunisola, measured from the date that Buddha found enlightenment. The problems we see on a daily basis with date and time handling are because people either don't understand the complexities of the problem they're trying to solve. or they don't care, or they don't communicate the limitations of the solution they've used, or they're willing to make those limitations somebody else's problem in the future. Which is exactly how he got Y2K. A generation of programmers took the vernacular of the time and wrote systems that stored the year using two digits instead of four, seventy-five instead of nineteen

Speaker 2: seventy-five. And in 1975, the math worked fine and bytes were actually expensive, so it was kind of worth it. But come 1999, that shortcut transforms from a space-saving optimization to a major engineering headache. And yet, despite the fact that as an industry, we went through this 18 years ago, I still see official forms that ask for a date and provide two boxes for the year. And we're lining up for a repeat performance in less than 20 years. Many computer systems store time using Epoch, the number of seconds since midnight UTC January 1st, 1970. Which will be fine right up until 3. 14 in the morning on January 19, 2038, when that count will be larger than what you can store in a signed 32-bit integer. And if you're inclined to think, oh, that's a problem we'll solve in the future, oh well we will be using 64-bit machines by then, well firstly you want to guess how much 1970s COBOL code had to be updated in 1999.

Speaker 2: And secondly, we've already seen epoch bugs. In May 2006, AOL's servers crashed. Why? Because their code involved generating events that should never time out. And the programmer used a hack. They just added a billion seconds to the current timestamp whenever they created an event, which was fine until 127 in the morning on May 13, 2006, when adding one billion seconds to the current epoch overflowed the 32-bit signed limit and never happen events were being created with an already expired timestamp. But here's the thing, there's a very fine line between really cool hack and horrible nasty hack. Generally, it's a really cool hack right up until everything breaks horribly. But

Speaker 2: All computer systems have limitations. All computers make assumptions. The problem with AOL server wasn't that they used a hack to make dates not expiring. The problem with Y2K wasn't that the system used two characters to store a year. The problem was that the technique that was used set a hard deadline for the end of life of that code. And that end of life either wasn't understood at the time, wasn't institutionally communicated, and as a result, when the clock ran out, hilarity ensued. Okay, so how do we bide our time with Python? Well, there is not surprisingly a Python module named Time. Time is a library for thinking about time the way your computer thinks about it. It contains multiple clocks. There is wall clock time, which is epoch. There's monotonic time, monotonic time, something you

Speaker 2: that matters if you're coordinating between multiple servers. There's CPU time, which is the time as observed by your CPU, and there's a performance counter, a very high resolution timer that doesn't have a good baseline. These different clocks all have different resolutions, different baselines, and as a result, different use cases. Internally, they measure store time as offset against some baseline, usually an integer or a float. Some methods accept or return a data structure called struct time, which is a thin wrapper around an operating system data structure that captures a bunch of time-related details. year, month, day of the month, hour, minute, second, but also the day of the week, with Monday being day zero, and the year day, the index of the day into the year. It all ha also has an is DST flag, which can be 0, 1, or minus 1 for no, yes, and don't know.

Speaker 2: Structure time And the rest of the time module operates on what's called local system time. So whatever time zone your operating system thinks it is, is what time you'll get That time zone can then be manipulated at a system level, but also at a user level using an environment variable, so there are multiple places in your server stack where your understanding of time can be modified by settings outside your own code. But the good news, in practice, unless you're doing something that interacts with epoch in some way, time is almost certainly not the module you want to be using. And if you're dealing with epo if you're dealing with epoch and you're not dealing with hardware, you're almost certainly doing it wrong. The module you probably want for most of your date and time requirements is the DateTime module. DateTime contains tools for dealing with dates and times at a human level, days, months, years, hours, minutes, seconds, and so on.

Speaker 2: The constructors all seem relatively straightforward. If you actually use these constructors, though, you're going to have a bad time Take the first one for instance. That's a date. Sure. Where? Every conference call for papers has this problem. The PyCon Australia call for papers, for example, closes on May 28th. May 28th, where? Okay, so you just attach a time, right? Yeah, but what time zone? Well in the case of Pycon Australia, it's AOE anywhere on Earth, which means you've got almost four days left to submit your proposal. Get on that. But okay, what about things that really did actually happen on a date? You know, like births and deaths, they're all on a day, right? Well, as soon as you don't have information for a date you've lost vital context. And if you try to do math without the context, you're going to get bitten.

Speaker 2: Someone asked Google Now how old is Stephen Hawking and got the response, Stephen Hawking died tomorrow at age 76. Stephen Hawking did die on March 14th, and he did do a lot of interesting things with space-time. But without knowing that he died in England and the person asking the question was in the US, where it was still March 13th, you can't do the math You're missing vital information. You make an assumption. And the assumption has, in this case, hilarious consequences. And if you specify time information without a date, the time also loses context and you get some similar problems Okay, so that means we should generally be using date times. The constructor for date time has one non-obvious part though, TZ info That's the time zone info. Now if you don't provide a TZ info

Speaker 2: object when you construct your datetime object, it's what's called a naive date time. And for most practical purposes, it's useless. A date and time without a time zone is an accident waiting to happen. If you do provide a TZ info object, what you have is called an aware date time, and that's something you can actually work with. Okay, so where do you get a TZ info object from? Well, to make datime actually useful, you actually have to use a third-party module, and the module you should probably be using is called PyTZ. I'd argue if you're doing anything with dates and times and you don't have PyTZ as a dependency, you are almost certainly doing dates and times wrong. It's a third-party module because it can't be built into Python or into Django. And one of the re the reason why is another one of those human things. PyTZ is a wrapper around the Olson

Speaker 2: Time Zone database. The Olson database is published as a set of text files in a human readable format, which are themselves hilarious to read. These are compiled into machine readable format for use by libraries like PyTZ. It contains a list of time zones, an offset of that time zone from UTC, the time at the Greenwich Prime Meridian, and it is published. regularly, multiple updates per year. The current database is called the 2018 E database. It has had five updates this year That regular update cadence cycle is why it can't be part of Python itself. It has a release cadence that isn't compatible with Python's. The 2018 e database was published on March May 4th. Because North Korea gave the world five days notice that they were going to change their time zone to match South Korea.

Speaker 2: Sometimes countries make these changes retrospectively. Okay, but like why is a whole database format needed? Your d your time zone is just an integer number of hours off from GMT at an hour for daylight savings, right? No. Here are some amusing selections from the Time Zone database file. Darwin and the Northern Territory of Australia observe a 9 hours and 30 minutes offset from UTC. Adelaide and South Australia observes a 9 hours and 30 minutes offset, but with 10 hours 30 during daylight savings. But the daylight savings transition transition dates are different to the dates used in the US and Europe because we're in the Southern Hemisphere, so summertime is six months out of phase. Broken Hill is a town in the state of New South Wales.

Speaker 2: Even though it's in New South Wales, it observes South Australian time. But it uses New South Wales dates for daylight savings transitions. Which most of the time is the same, but not always. Eucla is a very small border town in Western Australia, population about 300. It doesn't observe Western Australian standard time of plus eight hours. It uses eight hours and forty-five minutes offset. Except when Western Australia observes daylight saving, which it generally doesn't, except for about every 20 years when the government goes on a spree and decides it's going to experiment for a couple of years and then go back to not having daylight savings again. Lord Howe Island uses a 10 hours and 30 minute offset during the winter and offsets by 30 minutes for daylight saving We haven't even left Australia yet.

Speaker 2: This region down here doesn't look anything like this. It looks like this. And last I heard there was a Django deployment in Antarctica, so this is a case the Django core team have to care about. Even this map can potentially get you into trouble. The border of Kashmir is a disputed region between India and Pakistan. All maps in India have to show the whole of Kashmir as part of India. and foreign publications have to stamp near each incorrect map to say that it does not represent the true map of India as per the instructions of the government of India. So Windows 95 was threatened with a ban in India because of the way Windows displayed its time zone map. Similar problems occur for occupied and disputed regions all over the world. Time zones can't always be determined by a simple mapping polygon And for this reason, PyTZ doesn't include geography, it just has the time zone names.

Speaker 2: So, once you've installed PyTZ, pip install PyTZ, you can reference any time zone by name or just use the UTC time zone. Actually using that time zone object, however? That's a little more difficult. So surely we just create a PyTZ object and create a date time, right? Well, no. What's wrong with this picture? It's 4. 46 pm, 25th of May 2018. LMT plus 53 minutes? What's LMT? Where did 53 minutes come from? Well, back in the day, time zones weren't something that was shared across the whole of a continental region. They were based on train timetables, and every train station kept its own concept of time. The only b it only it's only when we got centrally coordinated time that the idea of Central European Standard Time existed. And when you try to map historical times onto modern time zones, you get some interesting offsets.

Speaker 2: Berlin, for example, was 53 minutes ahead of LMT. LMT is local mean time. It's essentially the same as UTC, but UTC didn't exist until 1960. And because LMT plus 53 minutes is the earliest chronological entry in the Olsen database for Berlin, in the absence of any other information, that's the one that gets used. So time zones are time-sensitive, which if you think about it makes sense because you can't apply summertime for a date in the middle of winter. So what you need to do is create a naive date time object and then localize that object. When you localize, the time zone definition can then take into account the date you're converting and construct the appropriate TZINFO object. So, the datetime module gives you primitives for storing dates, but those primitives are difficult to construct.

Speaker 2: And unfortunately, it's even harder when you consider that in many cases the data isn't coming in in nice clean, well-sorted numerical formats. The problem of parsing dates from text is one of the areas where Python standard library has limitations. And it's not because the standard library is bad, it's because it's a hard problem. And it's a hard problem because of People. So today is May 25th. Next Friday is the first of June 2018. I mean it's June 1st, 2018. I mean it's 2018's June 1st. Day, month, year, month, day, year, and year, month day are all common orderings for dates depending upon where you are in the world. And if you're accepting date input, you have to be aware that there are cultural variations in the way people represent dates.

Speaker 2: And sometimes all three numbers are valid. Date time has a mechanism for parsing dates, STRP time. If you happen to know the exact format that your humans will be importing dates, it generally works fine. The problem is that you probably don't know the format that your humans will be providing dates. Ah, standards to rescue. ISO 8601 is the international standard format for representing dates, and like all good international standards, it's the format nobody actually uses. It uses year, month, day, hour, minute, second in a very precise format with then either a UTC offset in hours, minutes, or Z for Zulu or UTC time. It is also, unfortunately, a format that DateTime STRPTime doesn't parse natively. There's also a subtle problem lying in wait with any ISO 8601 format DateTime.

Speaker 2: ISO 8601 specifies the time in hours, minutes, seconds, and then specifies a UTC offset in hours-minutes. Which means we've got a problem because a UTC offset isn't a time zone. Take my own time zone, UTC plus eight hours. It's not just important because of me. One-sixth of the world's population lives in my time zone. So what 8 UTC plus 8 hours won't tell you is which time zone those people are living in. So it uniquely identifies a point in time, but it doesn't help you work out the right format for a particular user. And it doesn't tell you if any of those places are observing currently observing daylight saving time or when daylight saving time goes into effect Dealing with dates is clearly a very very complex problem and so lots of people have tried their hands at doing it better.

Speaker 2: Date Util, Arrow, Moment, Meyer, DeLorean, they're all PyPI modules that attempt to make date time handling easier and date parsing is one of the areas that they've tackled. Whether they've succeeded or not is a bit of a value judgment. They do tend to be more flexible in what they accept as valid input. However, the price paid for that flexibility is occasional inaccuracy. No amount of fancy logic will tell you whether one hundred sixty eighteen is June first June 18 or January 6th. So your mileage may vary. If you use these libraries, be aware they are not magic wands for fixing date handling. They make assumptions. Those assumptions have consequences. And that's not a bad thing. All code makes assumptions. You just need to be aware what assumptions you are making and validate that those assumptions are reasonable.

Speaker 2: But once you've been able to parse in date and time, you've got a time zone, you've got a valid timestamp. Now we just need to keep it that way, which is harder than you think. So we've created our timestamp. We can now do some date time math. What time was it 10 minutes ago? Well we use time delta, which is part of date time, and we get the time 10 minutes ago. Fantastic. Great Let's try a different time. Say 3. 05am, March 25th, 2018, Central European summer time. What time was it 10 minutes ago? Well we just subtract 10 minutes, right? Well no, because that says the time 10 minutes ago was 2. 55 Central European summertime. But at 2 a. m. March 25th, Central European time zone started daylight saving. So 255 CEST doesn't exist.

Speaker 2: The date time makes no sense. No accurate clock read 2. 55 a. m. and CEST started at 3. What you need to do is normalize the time zone. Normalization takes a time zone aware object and adjusts TZ info to be correct for the time that is currently being stored. In this case, the time 10 minutes before 3. 05 a. m. was 1. 55 a. m. Central European time. And you need to do this every time you do date time math. Because of another edge case, leap seconds. Just as a leap year exists to adjust the calendar year relative to the solar year, a leap second exists to adjust the solar day against the calendar day. Leap seconds are an extra second added to the last day of the month, usually

Speaker 2: December or June, but the standard does actually allow for it to occur in any month. There's no fixed schedule for adding leap seconds. They are announced about six months in advance, and they result in clocks that legitimately read 235960. And although it's never happened, 2359. 61 is also illegal time. Leak seconds can also be negative, so 2359. 59 might not occur on a given date. Leap seconds have been around since the 1970s, and yet Apple, Amazon, Netflix, Pinterest, Instagram, and Twitter had a 40-minute outage in 2015 because of a leap second bug in a router they were using. Cloudflare had an outage in 2016 because their DNS resolver didn't account for leap seconds. The New York Stock Exchange routinely stops operations for 61 minutes during leap second

Speaker 2: transitions to make sure they don't have problems. So, any math around date times is inherently difficult too. So you've got yourself a date time object, you know the time zone of the person who gave you the data, you parsed it correctly, and we've made sure that we've got the math right when we transformed it. Now it's time to display to another user. This means we need to know the time zone of the person reading the data in order to display it. And all of the same problems happen all over again. Time zone offsets, formats, all these problems exist on the display end as well as the input end. If you've got a time zone aware date time object, converting to other time zones is relatively straightforward. You can always use an as time zone method on the date time object itself. But you need to make sure you actually know the time zone that you're targeting. But there's another trap that developers and designers fall into.

Speaker 2: They do it with the best of intentions, trying to make numerical dates seem more human. When you say your product is going to be released this summer, or for the Americans, this fall, everyone south of the equator rolls their eyes. If there's any possibility your audience is intent uh is international, please don't use phrases like this. They aren't helpful They like an inside joke. They're great if you know the context, but just plain confusing if you don't. And if your intention is to communicate effectively, why would you intentionally be confusing? And you may think, oh, but my my audience is all local, they all know this. Really? Tell me more about that. What about recent immigrants? What about people from outside the country who need to use use your service? There is no service more American than the IRS, the US Tax Office.

Speaker 2: I am an Australian citizen who has lived in Australia my entire life, but I have to dig through the IRS website to work out how to sort out my tax affairs with my employer. When they say they're closed on Labor Day, well, for me, Labor Day is the first Monday in March. So why is the IRS closed in September? My humble request for anyone doing any sort of date time-based design is when you're using dates, consider how they're going to be consumed If you ever display a date, always display a year. Always use a text version of the month localized for your reader. Always display a time zone. And in logs, always use an ISO 8601 format. Details like year and time zone don't have to be front and center in your design. They can be like a column heading or a hover text, but include it somehow. Reading a blog post that says published 3rd of May without a year, how do I know if this information is current or not?

Speaker 2: And if you're trying to correlate between the log of a database and a log of a web server, and you've got a timestamp precise to the millisecond, and then you work out the two events are different by eight hours because one of them is in Perth time and one of them is in UTC. That's fun. Or more likely in Django installs six hours out because one is in UTC time and one of them is in Chicago time. Thanks, Adrian. So, in summary, a date means nothing without a time. A time means nothing without a date. Both of them are meaningless without a time zone. Or more specifically, an accurate time zone. Resist the temptation to guess. Every time you guess someone's time zone, assume you're going to get it wrong. When you read dates localize for the author's format and do everything you can to get that right, once you've got time zone information, don't ever lose it because you can't get it back.

Speaker 2: Localize for the reader on output and consider how that output will be consumed. Not just now, but in a year from now, two years from now In many respects, there's a really strong parallel here with Unicode handling. The fundamental thing about getting Unicode right, you need to know, not guess, know what format your data is in Is it ASCII? Is it Latin 1? Is it CP1252? Is it UTF-8? Or is it actually a Unicode string? Porting from Python 2 to Python 3. forced you to pay attention to this detail and verified every step whether the data you had was a Unicode string or data encoded in a particular format. And if it was encoded, what format was it in? If you've got an existing blob of bytes and you don't know its format, it's really, really hard to accurately reverse engineer that format.

Speaker 2: You can guess, your guess might even work, right up until the point that it doesn't. Similarly, if you don't have or you lose date, time or time zone information related to a timestamp, it is almost impossible to reverse engineer accurately. The only solution is to be rigorous from the outset and make sure at every step of the process you know what you have. Once you've got it, don't forget what you've got. The good news, if you think time is hard now, you ain't seen nothing yet. We are as a species on the cusp of becoming interplanetary, which means certain basic assumptions about dates and times are about to go out the window. A day on Venus is longer than a year on Venus. A day and a year isn't the same length on any two planets. So what's going to happen with times when a day isn't 24 hours long, or time zones when two planetary times overlap?

Speaker 2: What about signal propagation time between two planets? Now, okay, you're probably not going to have those problems this week at work, but GPS satellites already require date-time calculations that involve adjustments due to special relativity. So it's not as far off as you think. And besides, how many YUK problems do you think were caused by someone thinking they didn't need to worry about the distant future of the year 2000? But my time is running out, so I'd better wrap up. As I said at the start, my undergraduate degree is in physics. Physics is the study of fundamental forces, and very early in a physics degree you get introduced to the idea of MKSA MKSA is the set of fundamental units, meters, kelvins, seconds, and amperes. And because the fundamental units are important, they've all been quantified.

Speaker 2: There is an ISO standard kilogram. It's a thing that defines what a kilogram is. You can hold it, you can compare it to other kilograms. And you can do the same with two samples of Kelvin, two samples of amperes. But you can't do that with time. Is this second the same length as this second? Who knows? You can't put a second in a bottle. Time's ephemeral, it just is. So don't feel too bad about time being hard. It is. That's just physics. And it's really easy to throw your hands up in the air and declare time zones, how do they even work? And I'll admit even I do that when I've been bitten by them for the third time in a day. But just like physics and humans, you can understand them if you put your mind to it and consider the full breadth of human experience, treat it as a challenge rather than an impossibility, and plan.

Speaker 2: And like all planning, the best time to plan is ahead of time. Lastly, if I may, quick plug. As I mentioned at the start, my open source contributions at the moment are mostly focused on Beware, making Python a viable development platform for native apps and mobile platforms. That's not my day job. The simple fact is that time is money. Financial support means faster progress. If you like what you heard today, if you want to help me and the BeWare project progress faster, one way you can do that is to join the project as a financial member. Plan start at US $10 a month. Details on that link. If you want to learn more about Beware, or you have fresh ideas on how to monetize open source, or you just want to chat about weird time zones and cool clocks, please get in touch. Thank you very much.