It's time for datetime
Corchero, Mario
Working with time is not a trivial challenge. Python includes a native modulein the standard library to work with it but datetime keeps being together withunicode a common source of errors. This often leads to the widespread of manyother libraries in the attempt of easing the work of working with datetime.Datetime is one of those API that looks easy to use but given the manyconcepts around time, is it easy to get backfired if the developer has notsolid knowledge about the them. In this talk we will overview the main concepts about timestamps representedthrough datetime objects, the limitations on the standard library and somesimple steps to try to avoid the common mistakes that everyone can fall into. Naive datetimes (which the datetime API works by default with) are a greattool to represent calendar times, but when talking about timestamps (focus ofthis talk) timezones is n essential part of it and the datetime module can betricky to use for that use cases. We will also speak about different standards of time, time zones, DaylightSaving Times, leap seconds, serialization and datetime arithmetics. The talk will be focused on giving the foundations that everyone knows to beable to understand and work efficiently and without making painful mistakeswhen dealing with time related algorithms. # Audience All developers face a time when they have to work with datetime. This isclearly not a simple domain to just jump in to. The talk will help beginnersand intermediate developers to understand and don’t subestimate the complexityof working with time. The most experiences developers will also have some takeaways and pointers to further their grasp of this tricky field and gainconfidence on their daily usage of time related libraries. The talk will include explanations of what “time” actually means and how canwe represent it in python. You don't need to be an expert in datetime nor ISOstandards, the attendees will leave understanding the complexity of time, themain concepts behind datetime and a list of tips to represent timestamps withdatetime in a painless way. The talk will also include pointers to solutionsfor more complex problems like leap seconds, the [foldattribute], etc.
 Hello everyone. Well, first I want to be sure when he said free beers, he'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. Very well. So my name is Mario Grachero. I work at Bloomberg. And I'm here today to think about data. I'm working in New South Domain and I went through a lot of pain when working with time-sensitive applications in Python. And I just want to share my experience to even 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. 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. We had this moment, which is like the blue to 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, 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, you mentioned the second as 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, you know, when we see the solar time. So whenever you see that the earth 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 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 a constant as possible frequency. We realized that micro-webbing session makes it L-extranged oscillate at a very nearly constant frequency. Yet I read it. I couldn't memorize that sentence. And so we started to build atomic clocks which are just using session. And this is great. This is what's being used for astronomical times. This is what Thai standards 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 moment engaged in getting this really precise time and measure of the second. But then UTC came. UTC is what you all want to use. It's 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, for us, so was the 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 and UTC offsets. So 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, yeah, minus five hours. No, my platform, you can check it. 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 kinds of weird time zones, like some countries being hours and a quarter and hours and 45 minutes. All kinds of crazy things that 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 where everyone in there follows the same standard time. So 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. Time stands is just an absolute point in like the absolute line of 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 kind of 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 time stand. So if in Python you have a daytime library, which is part of the standard and is 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. So that's where is the 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 like it's implicit the time zones. You cannot get an absolute point of time out of this. Those times are referring Python as naïve daytime, in opposed to daytime's on the word daytime's, which are the daytime's that have a time zone attached to it. And Python, 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 whenever you set the offset so you get a time zone or a daytime. When you call now, whenever you create the daytime, just remember to pass the time zone if you want an absolute point on 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 sure 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, okay, I'll just pass the time zone and that's it. And then DST came. 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, this will save light because people will be more time awake when there is light on the sky, right? 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, it's only a 1% of the total money and it comes with all kind of hassles like, you know, 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 will 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 as 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 Europe, Brussels. This is using the Olsen database, which is available with PyTZ. It was the recommended library until 3.6. From 3.6, you should be using 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, this is central European summer time, the offset is plus two and you get daylights having time. This, like, you know, 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 to use them. Just use UDC. Whenever you can, just use UDC and you'll be fine. And it's really that 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 that you save as well the time zone and use this convert on the borders. It's like Unicode. You do this Unicode language. So I would do the same with the time zones. You can use both PyTZ or DataUtil. You just call, whenever you get a day time with UTC, all conversions are saved from that one. If you create the date with other ones, it's not just 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 DataUtil or with PyTZ. And this is a safe conversion and you will get a day time for whatever time zone that you ask for this. Next, you cannot map a future all the 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 can'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. Well, it's not because countries will change the time zones. Countries will just decide to stop following DST and they will actually 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 PyTZ or DataUtil 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 four people has one less day. Well, maybe they go to pay the same salary and work one less day. How do 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 the 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, right? You just don't want to format it however you want. You might be thinking, like, come on, we are Europeans. Within that date is a day, month, year, hour, minute, second. Turns out that in the US, they actually do month, day, year. I know it sounds crazy, but well, whatever. 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 know, you're using a standard. You can rely on that. You can tell other people 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, 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. And 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 where the clock goes forward one hour. So the horrible tip I'm going to give you is just think about it. Like, I'm probably dead, you have assumptions. Just test whether we are doing it. The image has nothing to do with what I'm saying. Just, yeah, I guess 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 previous data which you shouldn't, and then be aware that if you are doing arithmetic on daytime 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 are using PyTest, which is even worse when dealing with that, they do do fix that. If you are using PyTest, you need to call local, 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 is going to 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. Then use as time zones to convert the user time zones on borders. Keep your time zones database updated, whether you are using PyTest or DPUTIL. Use ISO formatting for when you need to send the odd 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 were mentioned in PyTest, just the awesome database. They do a lot of cool things and proper time zone support. 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 time zones they do to UTC. Our own pendulum are just dropping replacement for daytime. AstroPy is great to deal with leap seconds. And Friskan, this is the library that's going to save your life because it allows you to test with time. You can say, I want to test with us in this day or any specific days. It will allow you to validate that you so far behave as you expect when you have all this kind of awareness with time. So now we're going to see some code samples. There is a camera in the room which is rendering life if you are 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 up. And there is 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 see where 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 going to be any problem with this? So you have a time zone. You get the sonar client and then you localize whatever nath 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 or what? So yeah, it's still the people that answer. More than anything, all right. This is going to cause you problems. Because when you localize a nath daytime with a time zone, this function has a beautiful parameter called ESDSD, which will tell you whether you are in the ESDD or not. Whether you, you know, whenever you are in this specific situations where you can have ambiguous times where there are some things 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 ESDSD equals none. And this is going to throw an exception in that situation. Next one. I'm really bad on time, so I'm going to 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 going to format it with this really cool format because this is what I learned at school. So the times are going to look like this. Who thinks this is good? All right, come on. Cool. Cool. You're getting better. 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 going to parse that. So you just use this format and whenever you parse it, you can use something like that.util.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 going to bet your salary on this. This is 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.999% of, that's great. You're an expert on daytime. So I hope you got to be careful with day times. If you're just a normal user of daytime, just stick UTC in, 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. This is just, so I'm a member of the organization of the Python Spain this year. It's a hundred of people coming, awesome city, awesome food. It's amazing, right? So beautiful. That's what I studied. And we really want you to welcome you. Basically, if you speak Spanish, if you don't, you're welcome. But we might have a track in English. 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. It's a 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. 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 a leap second? 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 be astronomical or something like that. But if you really have a look into Astropy, because that's a library that has supports for leap seconds, 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 today's... 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 Astropy. I don't know how long it takes to do that. We don't know the next five years' leap seconds. The UTC just decided, hey, leap second is here. One second more for you, so there's no way to know it. Do you know how far they can work on? So if I have a story of it? That's really interesting. It happens as well. I'm not sure about day detail. You can ask Paul, which works at Paul Guns. He's the main maintainer of day-to-day utility. He works at Bloomberg. More promotion here coming. But yeah, it's an issue because, for example, daytime doesn't go further than, I think, 9,900 blvd. So you would have to... Astropy again has supports for really long and really past states. So you can have a look to Astropy. Do you have any tips on dealing with stringer-coupled parsed strings like the avenue parameter that you're going to have to parse stringer-coupled parsed strings? Especially on unhooked for error methods? Yeah, so day-to-day utility 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 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 are 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, you know, I have no idea what it is. Just give me back a daytime, and he 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 this time? It's time for another one. It's time for? Okay, cool. So on the slides, 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 work, right? Because, like, this has a different clock. This is not a session clock. I don't know how session smells, but there's not a session clock here. So there's a protocol called NTP, which is really interesting. If you like this all daytime craziness, how do you look at NTP is really, really interesting. That's all. Thank you very much. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 Hello everyone.  Well, first I want to be sure when he said free beers, he'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.  Very well.  So my name is Mario Grachero. I work at Bloomberg.  And I'm here today to think about data.  I'm working in New South Domain and I went through a lot of pain when working with time-sensitive applications in Python.  And I just want to share my experience to even 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.  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.  We had this moment, which is like the blue to 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, 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, you mentioned the second as 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, you know, when we see the solar time.  So whenever you see that the earth 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 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 a constant as possible frequency.  We realized that micro-webbing session makes it L-extranged oscillate at a very nearly constant frequency.  Yet I read it. I couldn't memorize that sentence.  And so we started to build atomic clocks which are just using session.  And this is great. This is what's being used for astronomical times.  This is what Thai standards 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 moment engaged in getting this really precise time and measure of the second.  But then UTC came. UTC is what you all want to use.  It's 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, for us, so was the 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 and UTC offsets.  So 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, yeah, minus five hours.  No, my platform, you can check it. 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 kinds of weird time zones, like some countries being hours and a quarter and hours and 45 minutes.  All kinds of crazy things that 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 where everyone in there follows the same standard time.  So 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. Time stands is just an absolute point in like the absolute line of 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 kind of 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 time stand.  So if in Python you have a daytime library, which is part of the standard and is 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.  So that's where is the 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 like it's implicit the time zones.  You cannot get an absolute point of time out of this.  Those times are referring Python as naïve daytime, in opposed to daytime's on the word daytime's,  which are the daytime's that have a time zone attached to it.  And Python, 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 whenever you set the offset so you get a time zone or a daytime.  When you call now, whenever you create the daytime, just remember to pass the time zone if you want an absolute point on 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 sure 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, okay, I'll just pass the time zone and that's it.  And then DST came. 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, this will save light because people will be more time awake when there is light on the sky, right?  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,  it's only a 1% of the total money and it comes with all kind of hassles like, you know, 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 will 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 as 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 Europe, Brussels.  This is using the Olsen database, which is available with PyTZ.  It was the recommended library until 3.6.  From 3.6, you should be using 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, this is central European summer time, the offset is plus two and you get daylights having time.  This, like, you know, 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 to use them. Just use UDC.  Whenever you can, just use UDC and you'll be fine.  And it's really that 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 that you save as well the time zone and use this convert on the borders.  It's like Unicode. You do this Unicode language.  So I would do the same with the time zones.  You can use both PyTZ or DataUtil.  You just call, whenever you get a day time with UTC, all conversions are saved from that one.  If you create the date with other ones, it's not just 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 DataUtil or with PyTZ.  And this is a safe conversion and you will get a day time for whatever time zone that you ask for this.  Next, you cannot map a future all the 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 can'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.  Well, it's not because countries will change the time zones.  Countries will just decide to stop following DST and they will actually 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 PyTZ or DataUtil 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 four people has one less day.  Well, maybe they go to pay the same salary and work one less day.  How do 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 the 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, right?  You just don't want to format it however you want.  You might be thinking, like, come on, we are Europeans.  Within that date is a day, month, year, hour, minute, second.  Turns out that in the US, they actually do month, day, year. I know it sounds crazy, but well, whatever.  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 know, you're using a standard. You can rely on that.  You can tell other people 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, 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.  And 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 where the clock goes forward one hour.  So the horrible tip I'm going to give you is just think about it.  Like, I'm probably dead, you have assumptions.  Just test whether we are doing it.  The image has nothing to do with what I'm saying.  Just, yeah, I guess 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 previous data which you shouldn't,  and then be aware that if you are doing arithmetic on daytime 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 are using PyTest, which is even worse when dealing with that, they do do fix that.  If you are using PyTest, you need to call local, 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 is going to 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.  Then use as time zones to convert the user time zones on borders.  Keep your time zones database updated, whether you are using PyTest or DPUTIL.  Use ISO formatting for when you need to send the odd 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 were mentioned in PyTest, just the awesome database.  They do a lot of cool things and proper time zone support.  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 time zones they do to UTC.  Our own pendulum are just dropping replacement for daytime.  AstroPy is great to deal with leap seconds.  And Friskan, this is the library that's going to save your life because it allows you to test with time.  You can say, I want to test with us in this day or any specific days.  It will allow you to validate that you so far behave as you expect when you have all this kind of awareness with time.  So now we're going to see some code samples.  There is a camera in the room which is rendering life if you are 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 up.  And there is 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 see where 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 going to be any problem with this?  So you have a time zone.  You get the sonar client and then you localize whatever nath 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 or what?  So yeah, it's still the people that answer.  More than anything, all right.  This is going to cause you problems.  Because when you localize a nath daytime with a time zone, this function has a beautiful parameter called ESDSD,  which will tell you whether you are in the ESDD or not.  Whether you, you know, whenever you are in this specific situations where you can have ambiguous times where there are some things 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 ESDSD equals none.  And this is going to throw an exception in that situation.  Next one.  I'm really bad on time, so I'm going to 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 going to format it with this really cool format because this is what I learned at school.  So the times are going to look like this. Who thinks this is good? All right, come on.  Cool.  Cool.  You're getting better.  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 going to parse that.  So you just use this format and whenever you parse it, you can use something like that.util.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 going to bet your salary on this.  This is 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.999% of, that's great.  You're an expert on daytime.  So I hope you got to be careful with day times.  If you're just a normal user of daytime, just stick UTC in, 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.  This is just, so I'm a member of the organization of the Python Spain this year.  It's a hundred of people coming, awesome city, awesome food.  It's amazing, right? So beautiful. That's what I studied.  And we really want you to welcome you.  Basically, if you speak Spanish, if you don't, you're welcome.  But we might have a track in English.  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.  It's a 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.  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 a leap second?  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 be astronomical or something like that.  But if you really have a look into Astropy, because that's a library that has supports for leap seconds,  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 today's...  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 Astropy.  I don't know how long it takes to do that.  We don't know the next five years' leap seconds.  The UTC just decided, hey, leap second is here.  One second more for you, so there's no way to know it.  Do you know how far they can work on?  So if I have a story of it?  That's really interesting. It happens as well.  I'm not sure about day detail.  You can ask Paul, which works at Paul Guns.  He's the main maintainer of day-to-day utility.  He works at Bloomberg. More promotion here coming.  But yeah, it's an issue because, for example, daytime doesn't go further than, I think, 9,900 blvd.  So you would have to...  Astropy again has supports for really long and really past states.  So you can have a look to Astropy.  Do you have any tips on dealing with stringer-coupled parsed strings like the avenue parameter  that you're going to have to parse stringer-coupled parsed strings?  Especially on unhooked for error methods?  Yeah, so day-to-day utility 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 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 are 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, you know, I have no idea what it is.  Just give me back a daytime, and he 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 this time?  It's time for another one.  It's time for?  Okay, cool.  So on the slides, 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 work, right?  Because, like, this has a different clock.  This is not a session clock.  I don't know how session smells, but there's not a session clock here.  So there's a protocol called NTP, which is really interesting.  If you like this all daytime craziness, how do you look at NTP is really, really interesting.  That's all.  Thank you very much.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
It_s_time_for_datetime_Painless_working_with_time_in_python_0_47.png It_s_time_for_datetime_Painless_working_with_time_in_python_48_131.png It_s_time_for_datetime_Painless_working_with_time_in_python_132_1655.png It_s_time_for_datetime_Painless_working_with_time_in_python_1656_5735.png It_s_time_for_datetime_Painless_working_with_time_in_python_5736_7439.png It_s_time_for_datetime_Painless_working_with_time_in_python_7440_16247.png It_s_time_for_datetime_Painless_working_with_time_in_python_16248_18671.png It_s_time_for_datetime_Painless_working_with_time_in_python_18672_19859.png It_s_time_for_datetime_Painless_working_with_time_in_python_19860_22691.png It_s_time_for_datetime_Painless_working_with_time_in_python_22692_22787.png It_s_time_for_datetime_Painless_working_with_time_in_python_22788_27263.png It_s_time_for_datetime_Painless_working_with_time_in_python_27264_27791.png It_s_time_for_datetime_Painless_working_with_time_in_python_27792_33371.png It_s_time_for_datetime_Painless_working_with_time_in_python_33372_34367.png It_s_time_for_datetime_Painless_working_with_time_in_python_34368_34667.png It_s_time_for_datetime_Painless_working_with_time_in_python_34668_34739.png It_s_time_for_datetime_Painless_working_with_time_in_python_34740_34787.png It_s_time_for_datetime_Painless_working_with_time_in_python_34788_39263.png It_s_time_for_datetime_Painless_working_with_time_in_python_39264_39527.png It_s_time_for_datetime_Painless_working_with_time_in_python_39528_39683.png It_s_time_for_datetime_Painless_working_with_time_in_python_39684_40259.png It_s_time_for_datetime_Painless_working_with_time_in_python_40260_40535.png It_s_time_for_datetime_Painless_working_with_time_in_python_40536_41075.png It_s_time_for_datetime_Painless_working_with_time_in_python_41076_41135.png It_s_time_for_datetime_Painless_working_with_time_in_python_41136_41195.png It_s_time_for_datetime_Painless_working_with_time_in_python_41196_41291.png It_s_time_for_datetime_Painless_working_with_time_in_python_41292_41711.png It_s_time_for_datetime_Painless_working_with_time_in_python_41712_41795.png It_s_time_for_datetime_Painless_working_with_time_in_python_41796_41915.png It_s_time_for_datetime_Painless_working_with_time_in_python_41916_42647.png It_s_time_for_datetime_Painless_working_with_time_in_python_42648_43127.png It_s_time_for_datetime_Painless_working_with_time_in_python_43128_43631.png It_s_time_for_datetime_Painless_working_with_time_in_python_43632_43979.png It_s_time_for_datetime_Painless_working_with_time_in_python_43980_44999.png It_s_time_for_datetime_Painless_working_with_time_in_python_45000_45119.png It_s_time_for_datetime_Painless_working_with_time_in_python_45120_45239.png It_s_time_for_datetime_Painless_working_with_time_in_python_45240_45287.png It_s_time_for_datetime_Painless_working_with_time_in_python_45288_45503.png It_s_time_for_datetime_Painless_working_with_time_in_python_45504_46631.png It_s_time_for_datetime_Painless_working_with_time_in_python_46632_46727.png It_s_time_for_datetime_Painless_working_with_time_in_python_46728_46747.png
Hello everyone. Well, first I want to be sure when he said free beers, he'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. Very well. So my name is Mario Grachero. I work at Bloomberg. And I'm here today to think about data. I'm working in New South Domain and I went through a lot of pain when working with time-sensitive applications in Python. And I just want to share my experience to even 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. 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. We had this moment, which is like the blue to 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, 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, you mentioned the second as 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, you know, when we see the solar time. So whenever you see that the earth 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 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 a constant as possible frequency. We realized that micro-webbing session makes it L-extranged oscillate at a very nearly constant frequency. Yet I read it. I couldn't memorize that sentence. And so we started to build atomic clocks which are just using session. And this is great. This is what's being used for astronomical times. This is what Thai standards 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 moment engaged in getting this really precise time and measure of the second. But then UTC came. UTC is what you all want to use. It's 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, for us, so was the 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 and UTC offsets. So 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, yeah, minus five hours. No, my platform, you can check it. 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 kinds of weird time zones, like some countries being hours and a quarter and hours and 45 minutes. All kinds of crazy things that 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 where everyone in there follows the same standard time. So 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. Time stands is just an absolute point in like the absolute line of 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 kind of 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 time stand. So if in Python you have a daytime library, which is part of the standard and is 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. So that's where is the 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 like it's implicit the time zones. You cannot get an absolute point of time out of this. Those times are referring Python as naïve daytime, in opposed to daytime's on the word daytime's, which are the daytime's that have a time zone attached to it. And Python, 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 whenever you set the offset so you get a time zone or a daytime. When you call now, whenever you create the daytime, just remember to pass the time zone if you want an absolute point on 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 sure 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, okay, I'll just pass the time zone and that's it. And then DST came. 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, this will save light because people will be more time awake when there is light on the sky, right? 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, it's only a 1% of the total money and it comes with all kind of hassles like, you know, 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 will 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 as 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 Europe, Brussels. This is using the Olsen database, which is available with PyTZ. It was the recommended library until 3.6. From 3.6, you should be using 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, this is central European summer time, the offset is plus two and you get daylights having time. This, like, you know, 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 to use them. Just use UDC. Whenever you can, just use UDC and you'll be fine. And it's really that 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 that you save as well the time zone and use this convert on the borders. It's like Unicode. You do this Unicode language. So I would do the same with the time zones. You can use both PyTZ or DataUtil. You just call, whenever you get a day time with UTC, all conversions are saved from that one. If you create the date with other ones, it's not just 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 DataUtil or with PyTZ. And this is a safe conversion and you will get a day time for whatever time zone that you ask for this. Next, you cannot map a future all the 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 can'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. Well, it's not because countries will change the time zones. Countries will just decide to stop following DST and they will actually 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 PyTZ or DataUtil 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 four people has one less day. Well, maybe they go to pay the same salary and work one less day. How do 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 the 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, right? You just don't want to format it however you want. You might be thinking, like, come on, we are Europeans. Within that date is a day, month, year, hour, minute, second. Turns out that in the US, they actually do month, day, year. I know it sounds crazy, but well, whatever. 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 know, you're using a standard. You can rely on that. You can tell other people 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, 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. And 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 where the clock goes forward one hour. So the horrible tip I'm going to give you is just think about it. Like, I'm probably dead, you have assumptions. Just test whether we are doing it. The image has nothing to do with what I'm saying. Just, yeah, I guess 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 previous data which you shouldn't, and then be aware that if you are doing arithmetic on daytime 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 are using PyTest, which is even worse when dealing with that, they do do fix that. If you are using PyTest, you need to call local, 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 is going to 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. Then use as time zones to convert the user time zones on borders. Keep your time zones database updated, whether you are using PyTest or DPUTIL. Use ISO formatting for when you need to send the odd 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 were mentioned in PyTest, just the awesome database. They do a lot of cool things and proper time zone support. 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 time zones they do to UTC. Our own pendulum are just dropping replacement for daytime. AstroPy is great to deal with leap seconds. And Friskan, this is the library that's going to save your life because it allows you to test with time. You can say, I want to test with us in this day or any specific days. It will allow you to validate that you so far behave as you expect when you have all this kind of awareness with time. So now we're going to see some code samples. There is a camera in the room which is rendering life if you are 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 up. And there is 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 see where 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 going to be any problem with this? So you have a time zone. You get the sonar client and then you localize whatever nath 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 or what? So yeah, it's still the people that answer. More than anything, all right. This is going to cause you problems. Because when you localize a nath daytime with a time zone, this function has a beautiful parameter called ESDSD, which will tell you whether you are in the ESDD or not. Whether you, you know, whenever you are in this specific situations where you can have ambiguous times where there are some things 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 ESDSD equals none. And this is going to throw an exception in that situation. Next one. I'm really bad on time, so I'm going to 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 going to format it with this really cool format because this is what I learned at school. So the times are going to look like this. Who thinks this is good? All right, come on. Cool. Cool. You're getting better. 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 going to parse that. So you just use this format and whenever you parse it, you can use something like that.util.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 going to bet your salary on this. This is 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.999% of, that's great. You're an expert on daytime. So I hope you got to be careful with day times. If you're just a normal user of daytime, just stick UTC in, 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. This is just, so I'm a member of the organization of the Python Spain this year. It's a hundred of people coming, awesome city, awesome food. It's amazing, right? So beautiful. That's what I studied. And we really want you to welcome you. Basically, if you speak Spanish, if you don't, you're welcome. But we might have a track in English. 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. It's a 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. 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 a leap second? 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 be astronomical or something like that. But if you really have a look into Astropy, because that's a library that has supports for leap seconds, 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 today's... 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 Astropy. I don't know how long it takes to do that. We don't know the next five years' leap seconds. The UTC just decided, hey, leap second is here. One second more for you, so there's no way to know it. Do you know how far they can work on? So if I have a story of it? That's really interesting. It happens as well. I'm not sure about day detail. You can ask Paul, which works at Paul Guns. He's the main maintainer of day-to-day utility. He works at Bloomberg. More promotion here coming. But yeah, it's an issue because, for example, daytime doesn't go further than, I think, 9,900 blvd. So you would have to... Astropy again has supports for really long and really past states. So you can have a look to Astropy. Do you have any tips on dealing with stringer-coupled parsed strings like the avenue parameter that you're going to have to parse stringer-coupled parsed strings? Especially on unhooked for error methods? Yeah, so day-to-day utility 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 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 are 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, you know, I have no idea what it is. Just give me back a daytime, and he 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 this time? It's time for another one. It's time for? Okay, cool. So on the slides, 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 work, right? Because, like, this has a different clock. This is not a session clock. I don't know how session smells, but there's not a session clock here. So there's a protocol called NTP, which is really interesting. If you like this all daytime craziness, how do you look at NTP is really, really interesting. That's all. Thank you very much. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
when working with time-sensitive applications in even fall into the same pitfalls. The main you'll see there are a lot of problems that can share this. This is not just about Python. This just by doing that, you can measure the time with time zones, like some countries being hours and a it. You just want to use an open source library But a time zone is just a region where everyone looks already complex, but we'll get into what day and a time in a specific location. And those part of the standard and is great, more or less, you a daytime without any kind of time zone. So it was giving you the time depending on what are and work one less day. How do you see it? But kind of this awareness? So just use a library have any kind of way to represent those. So you need to serialize them. The best way to do it is date and time-related objects. And you know, tips. Be aware of the different standards of time and know which one you are actually thinking you get from this talk, UTC. Then use as time to use the standards. We don't want just, come one is really tricky, but I know you are really good with day times already. So you want to get 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 expert on daytime. So I hope you got to be worry, this is not one of those slides where I'm Please come and we can speak about a lot of library that has supports for leap seconds, that much concerned about the accuracy of it. You can it. Do you know how far they can work on? So if I any tips on dealing with stringer-coupled parsed parser, which will try to infer the format. So