 Hello, everyone. First, I want to be sure, when he said free beers, it's not within this room. I see a lot of people here. Just to be clear, there's no beer here now. You should probably go out for it. Do well. So my name is Mario Gritero. I work at Bloomberg. And I'm here today to speak about data. I'm working in US automation, and I went through a lot of pain when working with time-sensitive applications in Python. And I just want to share my experience, so you don't fall into the same pitfalls. The main takeaway I want you to take from here is, if you are doing anything that is really time-sensitive, you'll see there are a lot of problems that can arise. So you really want to check and validate your assumptions. So let's see if it works. Yeah. So the first of all, something I really liked. And I wanted to share this. This is not just about Python. This is about daytime in general. I had this moment, which is like the Pluto Cape, where you see the real world and you see how complex daytime is. So the things like we gave measuring the time for granted. But if you think about it, it's the same problem as measuring distance. We can just use the meter to measure the things. But if you wouldn't have that, how would you be able to measure all the things? So for time, it's especially complicated. Because for meter, you can have something physical that can measure it. But for time, you just need a constant and a recurrent event with as constant as possible, with a frequency as constant as possible. So what I mean is if you, for example, want to do it, you can just measure the duration of the day or any other thing based on how long it takes to fill a bucket with water. If you are able to fill the bucket in a constant time. So you can say a day takes 100 times to 100 buckets to be filled, right? Lucky enough, we don't use buckets of water. We use the second. And I want to speak about some time standards that love, the one that we are still using. The first of all is UT1. UT1 is a fraction of the day, the day in the sense of the time it takes for the earth to do a full spin. And this is great. It's great for civil times. And now, before it was just being based on when we see the solar time, so whenever you see that the air has full compared to the sun, nowadays, we are using position of stars and more complex things. As a curiosity, if you ever wonder, why do we have 24 hours? It's because the Egyptians had a system based on 12, not a decimal one, because of the joints on the finger. You can read more about that. It's really cool. So then we were looking for this recurrent event, like with as constant as possible frequency. We realized that micro-webbing session makes it extra and oscillate at a very nearly constant frequency. Yet I read it. I couldn't memorize that sentence. And so we started to build atomic plugs, which are just using session. And this is great. This is what's being used for astronomical times. This is what Thai standard stands for. It's like international astronomical time. It's really, really precise. And it's actually so precise that the civil time in the Earth will deviate from it, which is clearly an issue. And to see how complex it is to compute it, all those many labs are the more engaged in getting this really precise time and measure of the second. But then UTC came. UTC is what you all want here is the saver. It comes with a lot of problems as well, but that's what everyone is using now. So this is a standard that measures the time the same way that Thai does. So it's based on session clocks. But so it doesn't deviate what it does. It has support to add a leap second every so often. We just had one in December. I don't know if you felt it. Your life was a second longer. And so just by doing that, you can measure the time with a really precise instrument. And you can keep noon being the time where the sun is in the sky, like in the top of the sky, but just at the leap second. This comes with a lot of problems for us so as developers, because now minutes can have up to 61 seconds. Well, we'll see more about that. So UTC came as well with the concept of time zones on UTC offsets. So a UTC offset is just an amount of time you will subtract or add from UTC to get your time. So the thing is like whenever you speak, the problem is you never speak on the time on UTC, right? If you're in New York, you are five hours, minus five hours. No, my plus four. You can check. The idea is you want 12 o'clock to be the time the sun is in the sky. So you will use time zones, sorry, UTC offsets. And then there is the concept of time zones, which is there are as many as you see here. And there are all kind of weird time zones, like some countries being hours and a quarter and hours and 45 minutes. And all kind of crazy thing that's come from political issues, as in my country wants to be in this time earlier than yours. And you just don't want to deal with it. You just want to use an open source library that will do it for you and just forget about it. But a time zone is just a region that where everyone in there follows the same standard time. I know this looks already complex, but we'll get into what kind of issue.com. And then the last comes that I wanted to introduce before going into some code is time stands versus world time. So there are two kinds of times. A time time is just an absolute point in the absolute line of time. Whilst the world time, so for example, the time star will have been born or the time a log was put into a file, something like that. Whilst world time is more like, I'll meet you in two weeks at two o'clock. It's just a day and a time in a specific location. And those just follow totally different rules to be more interesting, of course. So first of all, I'm going to give some facts and tips from the experience I had. So fact, a time without an offset cannot be mapped into a timestamp. So in Python, you have a daytime library, which is part of the standard, and it's great, more or less. But you have a method which is called now. You can use it to generate an instance of a daytime, and it's just returning your current time. If you just call it like this, it's going to just give you a daytime without any kind of time zone. And where is that date and time? You have no clue, right? I don't want to say it's ambiguous, because ambiguous has all the notation on daytime. But it's implicit in the time zones. You cannot get an absolute point of time out of this. Those times are referring Python as naive day times, in opposed to time zone or work day times, which are the day times that have a time zone attached to it. And something a lot from Python APIs, you cannot mix them, so if you compare them, you will get an inscription. So the tip is, just set the offset, so you get a time zone or work daytime. When you call now, whenever you create the daytime, just remember to pass the time zone if you want an absolute point of time. And this will give you, again, the same date, but with a time zone on it. And it will respect the time zone that you pass, because of the previous one. It was giving you the time depending on what are the times on your machine is configured, which I'm so you don't want, because you don't probably even know where your time to where your machine is, right? And yeah. So then when you see all this, OK, I'll just pass the time zone, and that's then DST comes. This is this great idea we had to save electricity many years ago, which is we will just move our clocks forward in sprint and move them back in autumn with the idea of it will look like the sunrise is later, but as well the sunset is later as well. So this will save light, because people will be more time awake when there is light on the sky. And this might have been great at the time, but at the moment, it has been so everyone agrees that whether it's saving or actually costing money is only 1% of the total money. And it comes with all kind of hassles, like all kind of problems in software development, because you have to deal with this craziness of one location having two different offsets. And as an interesting thing, because people have less sleep the day the clocks are moved, the Monday after the DST change is the day with the highest peak of suicide. So why are we still doing this, right? Some countries are moving out of it, but well. So fact, a time zone can have more than one offset. You can see here, we can get a time zone using the PyTZ model. And you can get the time zone in your Brussels. This is using the Olsen database, which is available in PyTZ. It was the recommended library until 3.6. From 3.6, you should be using that data. And here you can see, we passed a date in winter. And the offset is plus one. This is central European time. And this is standard time. Whilst if you take the date, which is in summer, if this is central European summer time, the offset is plus two. And you get daylight saving time. This, if you think about all the problems that come from here, if you're working with time zones that have DST, it's incredible. So my tip is, just don't use them. Just use UDC. Whenever you can, just use UDC. And you'll be fine. I know it's a really bad tip if you have to use time zones, because your clients are using time zones. So if you want to do that, I would suggest you that you save as well the time zone and use this convert on the borders. It's like Unicode. You do this Unicode sandwich. So I would do the same with the time zones. You can use both Pytocet or DateUtil. This is like this. You just call, whenever you get a date time with UTC, all conversions are saved from that one. If you create the date with other ones, it's not that. Just use UTC. So whenever you have an absolute point of time already, you can call us time zone and pass a time zone, which you can get both with DateUtil or with Pytocet. And this is a safe conversion. And you will get a date time for whatever time zone that you ask for this. Next, you cannot map a future world time to a time zone. It was like, come on. We already saw time zones. If I have a date and a time zone, why don't I get an absolute point of time? If I tell you meet you next Friday at 2 o'clock in Turkey, that's an absolute point in time, right? Well, it's not because countries will change the time zones. Countries will just decide to stop following DST. And they will likely give really short advice of it. Last example was Target, just deciding to stop following DST. And yeah, this can get really messy if you don't update your time zone database. This is a really important tip. You really need to update Pytocet or DateUtil or whatever you are using, because otherwise it's going to bite you back. You might be using a really old version of a time zone. And for some, also an interesting thing, there was a country that changed time zones from offset minus 12 to plus 12. And that meant that they missed the day in the year. So those poor people has one less day. Well, maybe they go pay the same salary and work one less day. Depends on how you see it. But yeah, can you imagine having to work with all kind of this awareness? So just use a library that supports this. Don't write your own stuff. So after all this painful thing, you just decide to send your daytime object, like a beautiful absolute point in time, into a JSON payload. And guess what? JSON doesn't support any kind of JSON work, right? Isn't that JSON? What stands for? So JSON doesn't support daytime. Sorry, it doesn't have any kind of way to represent those. So you need to serialize them. The best way to do it is use a standard. You just don't want to format it however you want. You might be thinking, come on, we are Europeans. We think that a date is a day, month, year, hour, minute, second. But turns out that in the US, they actually do month, day, year. I know it sounds crazy, but well, whatever. And month, day, year, I promise it's true. And in Japan, they do it the other way. They do a year, month, day. So just use a standard. There is ISO 8601. It has representation on the strings for all kind of date and time related objects. And you're using a standard. You can rely on that. You can tell other people, you just use that instead of saying, you know, I'd like to format my dates however you want. If you don't like strings and you want to use integers, you can use an epoch-based representation. The idea is you will choose a date. For example, for UNIX, the epoch for UNIX is 1970. And you start to come the second from them. So you just add one to the integer starting from that point. They are all kind of epochs like 1970, which is the most famous, it's just for UNIX. But that's also a way to sterilize an absolute point in time. By the way, UNIX time just is like UTC, but ignores the leap seconds. So where's the, oh yeah, fact. Time arithmetic can be really ambiguous. When you say I want to add a day to a daytime, what do you mean? Do you mean you want the same time but the next day? Do you want to add the number of seconds on the day? Because it's not the same, right? We say we have things like DST. And if you are here, you have some days that are 23 hours and some days that are 25. Because of the DST change, there is a point on the time where the clock goes back one hour and there's another point of the time when the clock goes forward one hour. So the horrible tip I'm going to give you is just think about it. Like, invalidate your assumptions. Just test whatever you're doing. The image has nothing to do with what I'm saying. Yeah, I saw some faces like, it's a tennis ball doing that. So just whenever you, if you are sensible to this kind of things like DST changes because you are not using UTC because you are not using the privacy I gave you, which you shouldn't, then be aware that if you're doing arithmetic on day times that are half time zones that follow DST, you might have issues because they might not behave as you think about them. And if you're using PyTZ, which is even worse when dealing with that, they too don't fix that. If you're using PyTZ, you need to call normalize after doing all kind of arithmetic. So review and the tips. Be aware of the different standards of time and know which one you are actually thinking about. But I mean, it's like, you might be thinking on like astronomical times that you might be using UTC and that it's gonna lead to some issues. Use fixed offset time zones if possible. Ideally UTC, UTC, UTC, UTC. That's what you get from this talk, UTC. And use asked time zones to converts to user time zones on borders. Keep your time zone database updated whether you are using PyTZ or Daybutyl. Use ISO formatting for when if you need to send your daytime as a string. Arithmetic operation can be tricky, so watch out. And remember that future world times cannot be mapped into a time zone. Some libraries worth mentioning. PyTZ, just the awesome database. They do a lot of cool things and proper time zone support. From, actually from starting from Python 3.6 with the addition of the Eastfold attribute. Pretty interesting if you want to read about it. They recommend the library to deal with times on this day due to UTC. Arom Pendulum are just dropping replacement for daytime. And AstroPy is great to deal with leap seconds. And FreeScan, this is the library that's gonna save your life because it allows you to test with times. You can say I want to, my test behave as in, it's this day or any specific days. It will allow you to validate that your software behaves as you expect when you have all this kind of awareness with time. So now we're gonna see some code samples and you have to, there's a camera in the room which is rendering life if you're right or not. And if you think the code sample is good, you put your right hand up. If it's bad, you put your left hand back. Your left hand up. And there's a camera that will give us the result in lifetime. So first of all, we just get the current daytime, right? We just want a timestamp for our logs and we call daytime. Hands up, exactly, 95.3% of the people know this is wrong. We have to use UTC. So we have to pass UTC to daytime now. Because otherwise your log will start to, you'll start to see weird things in the logs like time going forward and then going one hour back. And you don't want that, right? You want an absolute point of time. Next one, there's not much you can do here, but do you think there's gonna be any problem with this? So you have a time zone. You get that similar client and then you localize whatever napht daytime you had. So hands up, right, left. Wow, so many people participating in this. Wow, that's great. This is because of the beer, what? So yeah, it's still the people that answer, most of them are right. This is gonna cause you problems because when you localize a napht daytime with a time zone, this function has a beautiful parameter called East DST, which will tell you whether you are in the East Fold or not. Like whether you're, you know, whenever you are in this specific situations where you can have, you have ambiguous times where there are some times that appear twice because of the going forward and going backward of the hour, this will just silently give you one of the two and you don't even know which one. You can pass here East DST equals none and this is gonna throw an exception in that situation. Next one, I'm really bad on time, so I'm gonna skip this one. It's bad because the UTC again, right? And also because here we are relying on the time being monotonic and ascending and that's not always true. All of you are right, even if you didn't answer. What about this one? We want to send the time to a client and we decide like, hey, I'm gonna format it with this really cool format because this what I learned at school, so the times are gonna look like this. Who thinks this is good, all right, come on. Cool, cool, you're getting better, huh? 99.3%, yeah, we use this format, right? We want to use the standards. We don't want just, come on, think about the poor guy that's gonna parse that. So you just use this format and whenever you parse it, you can use something like that utility dot parse. There is no, or you can just use in daytime, you can use strp time to parse that. Last one really quick, because I'm out of time. You want to get the total number of seconds. This one is really tricky, but I know you are really good with day times already. So you want to get the total number of seconds on three years and you're gonna bet your salary on this. Is this good or bad? Come on, it's bad, it's bad. Great, exactly, 101% of the people got this right. That's new record. Why is this bad? Because Python doesn't deal with leap seconds, so this won't take into account the leap seconds. You know, for most of your use cases, it might be fine, but again, you just have to be aware of this kind of issues that you might face. In total, it's 99.99% of, that's great, that's great. You're an expert on daytime. So I hope you got the, be careful with day times. If you're just a normal user of daytime, just stick UTC and forget about all the problems. You have really time-sensitive applications. Just do some research, because it's really tricky. And last but not least, don't worry, this is not one of those slides where I'm saying like, come to have a coffee to our company, I will recruit you and everything. No, no, this is just, so I'm a member of the organization of the PyCons pane this year. It's a hundred of people come in, awesome city, awesome food, it's amazing, right? So beautiful, that's what I studied. And we really want you to welcome you, especially if you speak Spanish, if you don't, you're welcome, but we might have a tracking list, check the schedule. If you're a sponsor though, you should really have to look into it, because 20% of the people are unemployed in Spain. This is perfect environment for recruiting. That said, if you want to have a coffee on our, please come and we can speak about a lot of things like recruiting and all that stuff. That's all, I have some more material, if you don't ask any questions, and if you ask a question, I don't know the answer, my guinea pig will attack you this night. No questions? I have a question, how should we calculate the number of seconds with the leap seconds? Yeah, so if you want to take into account leap seconds when you're computing for example, a total number of seconds, I guess it's because your use case will probably something astronomical, something like that. You should really have a look into AstroPie, because that's a library that has supports for leap seconds, and that would be the right way to do it. That said, when you're doing operations like, I want to see how many seconds between two dates, and you are not that much concerned about the accuracy of it, you can just go with daytime. But for really accurate things, you should really go with it. AstroPie. They don't, like, we don't know the next five years leap seconds, like the UTC just decided, hey, leap second this year, one second more for you, so there's no way to know it. Do you know how far they can have a sort of data? Yeah, so that's really interesting. It happens as well. I'm not sure about day detail. You can ask Paul, which works, Paul Gansi is the main maintainer of day utility. He works in Bloomberg, more promotion here coming. But yeah, it's an issue because for example, daytime doesn't go farther than I think 9,900 blah blah. So you would have to, AstroPie again, has supports for really long, really past dates. So you can have a look to AstroPie. Do you have any practical tips on how to parse stringer presentations and especially draw unhelpful error methods? Yeah, so dayTutile has a parser, which will try to infer the format. So you can just pass any date to it, sort of like any string to it, and it will tell you, it will give you back a daytime. You want to use that only if you really don't know the format, because it tries to infer. I'm saying it because there is people sending millions of dates to it and complaining about being slow, and Paul has said, because it really tries to infer it. So if you know the format, or you have a guess of two or three formats, you can pass to the utility like, hey, those are the two or three formats I think they are. Otherwise you can tell him like, I have no idea what it is, just give me back a daytime, and it will do the best effort. You really need to do the format always. I have more content if you don't ask questions. How are doing with time? Is time full? Okay, cool. So on the slide there is something about, what's the difference with UTC and GMT? You can check it. And what's even more interesting is how does the, you know, because we saw all these time standards, but how does the computer works, right? Because like, this has a different clock. This is not a session clock. I don't know how session smells, but there's no session clock here. So there's a protocol called NTP, which is really interesting. If you like this old daytime craziness, have a look at NTP, it's really, really interesting. That's all. Thank you very much.