A Day Has Only 24±1 Hours: import pytz

Speaker 1 [00:06]

Thank you. A day has only 24 hours, more or less, and we have now less than 30 minutes to talk about them. What are we going to learn today? How to check the time? That you shouldn't check the time too often. You should check and follow what your government does. We are going to speak about time zones. My name is Miroslav Šidivý. I was born in Bratislava, in Czechoslovakia, in the time zone of Europe, Bratislava, studied in France, time zone Europe, Paris, now I'm working in Karlsruhe, this is the Europe Berlin time zones, and usually I'm using Python to make the sunshine and the wind blow. Now we are going to set the time, I'm not going to do any live coding, we are going to set the time to 16 of 3, Central European Summer Time, here in Karlsruhe and Germany. So this is the time that my whole talk is going to refer to. If you want to get the current time using standard Python library, you import time, that time, you get the Unix timestamp of the current time. If you ask for a time with a little bit more information, like year, month, and day, you can import daytime and then daytime, daytime now. If I do it on my computer, I will get something like this. If I do it on some server set to UTC, I will get something different. Two daytime objects that differ only in the hour attribute. So I want to have the same information on those computers, so I ask for the UTC time. Daytime, daytime, UTC now returns me on any computer the current time in UTC. But I want to know the information, to get the information that I am actually in UTC, so using standard Python libraries I can import the daytime time zone UTC and then refer it in my now method of daytime, daytime, and I get the information the current time with UTC attributes. This is absolutely perfect, legal, and very exact. If I want to get the local time, I know I am in Central Europe, we are still in summer until Sunday, and we have two hours offset to the UTC, so I can still, using standard daytime library, can I still define my own time zone with a stable offset. But this tells me, okay, it's the current time with offset of two hours comparing to UTC, but I have no information that next week there will be standard time and no more daylight saving time. I would have to adjust the hours offset manually. So I have to reach for a third-party library, and it's the PYTZ. In this case, if I ask for the current time in the time zone of Euro Berlin, I will get the current time, and that's the information that now we are two hours ahead of UTC. Next week it will be only one hour ahead of UTC. So this way, we can check the current time very well. The second point I mentioned at the beginning was don't check the current time too often. I want to know today, format today's date to your month and date. Okay, I get the current date. And then I want to know the date for yesterday. Current date, minus one day, and format it. If you do it in your usual working hours, it will work. Now, if these two lines are on a server in a program that may run at any time of the day, there will be one time of the day where you get unexpected results, and you are not going to be happy to be awakened from your sleep at midnight that this goes wrong. Because if these two lines are started just one microsecond before midnight, the first line happens before midnight, the second line after midnight, and the today and yesterday will be identical. Because today before midnight and yesterday after midnight are the same date. So you don't want to check the current time twice, just quickly after each other. The best way in a method, you ask for the current date, the current date time, and then you do all the mathematics with this, and all the results refer to the time of asking for date time, date time, UTC now, and not for two occurrences of this call for this function. There is one possibility in your program when you want to check for the time twice. It is when you want to measure some operation, so you check for the time at the beginning, then you have some expensive operation, and then you check for the time again, and then you calculate the difference. This doesn't really make a lot of sense to calculate with daytime objects because they contain too much information and you don't need the current here and everything you just need the current time, for example, in seconds from Epoch. So you can simply use it with time-time and then calculate the difference. You get immediately the difference in seconds. This works well, but if your expensive operation takes some time and in the same time the NTP date demon starts in your computer and sets the current time from Internet, then you will get, again, two different results. If I start and then my computer sets its time to the correct time because the last day was offset by a few seconds, the result will be wrong. During your extensive operation, you have time adjustment on your server, the result will be wrong. So there is a method from time, monotonic, that is guaranteed in one process to give you the exact time in seconds, referring to some starting point. So this will always work even if your expensive operation takes longer time and in between your process, your computer adjusts its time, its clock. Since Python 3.7, we can measure the time even in nanoseconds. So this was a little bit of computing. Now let's leave the computing and let's get back to the real life. How is time measured? It was always measured with the sun. Sun was at the highest point, somewhere about around noon. It was around noon, if you have already heard of equation of time. And maybe seen a form of like an eight on some solar clocks. This eight, it means that during the year, the highest position of sun oscillates by almost 15 minutes, in both directions and this is exactly the reason why we have this word mean in GMT Greenwich mean time this mean is the mean time during the whole year and on some dates during the year the sun can be in the highest position 15 minutes before or after so this was how people measured the time earlier then came railroad and the reason why we needed some one time for whole region or whole country. Greenwich was set as the base meridian, and some other countries, they had their own times. For example, in France, before 1891, every city had their own time zone, and then railroads said, okay, we are going to do one time zone. It is not for the passengers or that. It is just because on the single tracks, you want to be sure that you sent only one train from each direction at the same time so it's for the security and they established the standard french time on the leur de paris so the standard paris time and they added five minutes why if you ever run late to train you wish that the late the train was late by at least two or three minutes they made all trains automatically late by five minutes 1911 france adapted push date time to the Greenwich time, and the life was beautiful. We had standard 25 time zones, minus 12, plus 12, all around the world. And this was, except for the borders, like Europe looked like 100 years ago. So actually here, next to the Rhine, on the Rhine border to France, there was a time zone border, because France and UK and Benelux and Spain actually belonged to the West European time zone. They belonged until Hitler and Franco changed that. This would be beautiful, actually. This was the last time that physics, geography, and astronomy were, for the last time, in the power of determining the time zones after 100 years of ugly politics. So this is where my Python ends, and we are now going to speak about politics. There is no central authority for time zones. There is just one organization, Internet Assigned Numbers Authority, that tries to reflect everything. And they developed, they maintained a library called TZData. And this TZData is a library that you can get online. There is a source code with some programs and with some data information. And there is a mailing list. And there are people who just follow all the news around the world. as many as possible, and they try to identify, oh, they are going to change their time zone. Changing of time zone is not what happens now on Sunday. It is what will happen probably next year in Europe, when we are going to decide, okay, we don't do any daylight saving time, or we are doing just daylight saving time. And this is actually the changement. And there are hundreds of changements every year. If you import PYTZ in Python and you look at all the time zones, there are 591 time zones in the world. I'm not going to read them all now. Not now. Common time zones that are really in usage are still over 400. Distributed around the world, America, over 100. In Europe, we have 60 time zones. Even we are at the same time using like three or four different times. and this is how it looks like so this is now today so for example what you see in central Europe it is blue like I took six or seven colors and cycled through all times on so they are like every hour there is a different color and you see in Europe central Europe it's blue and in Africa it's a little bit to the east because this is the standard we are now in this daylight saving time that's why It's pushed a little bit to the west. And also the yellow with Portugal, UK, and in Africa it's more to the right. So this is the current state. These are 100 years of history in Europe. On the x-axis, you see the years from 1894 to 2037. So we are now 2019. You see approximately the dot. And on that side, you have to turn your head to the left. 0 is meridian, Asia, Australia is on the top, Europe is like in the middle, and America is on the bottom, if I look like this. And at the beginning you see like a lot of stripes, these are the local times, so they are like random minutes according to sun. Then it started to be a little bit more consolidated. In the 20s we had even less time zones, like only the 24, more or less, and these are daylight saving times. We have always like summer, winter, summer, winter. Then it stopped somehow. Then you see three or four long lines. This is like a simple metal plot, but it means that some island in Pacific moved one day ahead or back. So they just jumped through the whole time zone. And what you see also is we have the daylight saving time until 2037. This is the current state. If I don't update my BYTZ, my computer will keep changing, summertime, wintertime, for the next almost 20 years. But maybe next year it will change. So this was the world. Now we are going to check Europe. You see that usually the names of the time zones, like Europe, Berlin, it's located in Berlin. There is one exception you see south from Karlsruhe. you see a D-E, it's Germany, that's Büsingen. Do you know what Büsingen is? Schaffhausen is a Swiss city in the north of Switzerland, and there is an exclave, a small village that is surrounded by Switzerland, but it belongs to Germany. And in the end of the 70s, the Germans, they started with the daylight saving time like one or two years earlier, before the Swiss, but Büsingen kept it together with Zurich, with Switzerland, so that's why it's a special time zone. Now, everything is the same, but if we want to refer to some data from 1979-80, we have to keep this extra time zone. Usually most other countries in Europe have like one time zone, except for Russia, of course. So, and this is the history in Europe. What is interesting in the 2030s is around the one blue line that is a little bit offset. That is Netherlands, 40 minutes offset. But with World War II, Hitler, and then change from West European time to Central European time. In the top, there are some Russian cities. They don't observe daylight saving time anymore. If you just take time zone from PYTZ and you name it, then you will see in the string representation something like Berlin, 53 minutes. This was the first local London mean time plus 53 minutes. This is what was valid at the beginning of over 100 years ago. So now Berlin, of course, oscillates between plus one and plus two. So time zone object is not a stupid object. it contains already some functionality. And that's the reason why if you want to create a new daytime object, you cannot just tell TZInfo is Berlin, because if I convert it, it will just think, okay, it is 53 minutes ahead of UTC, and it will convert it accordingly. So if you want to localize some daytime object to a time zone, then you have to instantiate the time zone object and then localize, and then you get the right information and it knows whether you are in the daylight saving time or not. This is what I told about at the end of the 70s, beginning of the 80s, how different European cities started with the daylight saving time that works until now. It was really different times, different months, different days. There was Büsingen at the end that came with Zurich one year after Berlin. So this data, if you download it from the website of IANA, you will get 300 kilobytes of history of the humanity from the past over 100 years. There is some code, some pearl, oak, shell scripts, I think. But the most interesting files are Asia, Europe, North America. You see, Europe file is 160 kilobytes of text, and there is some code or some configuration file, but there is mostly text. text from mailing list with comments of people who tell, oh, there is a changement and I have read it in that newspaper, I have seen it on that website. We are going to have a look at a few examples. Berlin is quite boring. For Euro Berlin it's defined that now we are, until 1980 we were in the rules of Germany and then in the rules of EU and the rule of EU looks like this. You can recognize who remembers that until 1995, the end of daylight saving time was in September and not in October. It changed in 1996. So if now the European Union decides we don't use daylight saving time anymore, we just have to replace those smacks with 2019 and then add a few lines. So this is something that is stable and we can expect from the European Union that they are going to respect us, the software developers who have to cope with this. Not so in other countries. Istanbul, this is still Europe, but you see a few entries in 2011, 14, 15, 16. And the reason, on the 10th of March, 2011, they decided that they will go into the daylight saving time not on the 27th of March, but on the 28th of March, because of some nationwide exam. Imagine the time you need to understand this, reflect this, install this, roll out, and use it on all your systems. One year, no, three years later, they have some Turkish local election, so they are going to do it also a little bit later. The second note is from Randall Schwartz. Having landed on a flight from the States to Istanbul, nobody knew that this change meant. So it's something different if you are at home and the radio, they say, okay, we switched the clock, okay, but airplane systems, security systems, trains, everything operates automatically. You are not going to be able to switch it very quickly. 2015, Ministry of Energy, we are not going to switch to daylight saving time, and then they are going to switch. So actually, the code is just the last reflection, but these comments from the mailing list is there. I invite you really to read this. It's interesting. Caracas, Venezuela. Clocks advance 30 minutes on the 1st of May, but they announced it two weeks ahead. And there is, even there is some URL from Venezuela, so people have to read, like, Spanish okay, North Korean still okay, but there are also some other languages that are not so many people are able to read and to recognize that the government is going to do something. Port-au-Prince, this is Haiti, not far from Equator. In summer, they have 13 hours of daylight. In winter, they have 11 hours of daylight. And since eight years, they just, every year, two weeks ahead, are we going to do daylight saving time or not? And just really random. Pyongyang, North Korea, three years ago, they changed to 8.30 ahead of UTC instead of 9. Also, they announced it on the 7th of August for the 15th of August, so one week ahead. And then this year, on the 29th of April, oh, from the 5th of May, so again one week ahead, we are going to change back to the Korea Standard Time. And I started with these ideas of Daylight Saving Times and Time Zone in May, actually shortly after this was published. And then I tried on my computer. I have Arch Linux and Python just to ask what is the current time. And it said, oh, it's still 8.30 ahead. And then I switched to Shell. And I asked what is the current time. And it was nine hours ahead. The reason was that I had two packages. I have a package for TZ data that is used by the system. But on Arch Linux, PYTZ is not based on TZ data. It has its own library. So it means that if you have several libraries, several programming languages that bring their own EasyData version, it is possible that you are not in the same state. And then my Android is also 2016 and F. It has no idea that Korea changed their time zone. This is a problem if you have different systems that are depending on different sources, or if you even use, ah, I have a great library in Python that is much easier to use. You have to look where it takes the time zone information from. If it takes from DZ data, okay, at least you have one source of information. On the other hand, if you think, oh, I am going to write a perfectly tested application running in virtual env, conda, docker, and then don't touch it for the next 10 years, you will see next year that Europe probably stops using daylight saving time, but your PYTZ still knows that there is daylight saving time until 2037. So it's not so easy. Reading data, if you just read the data and in your string you have the offset, you can just use estherpytime. You can use also the dateutil library. It offers such possibility, for example, here. This is infos, and you define a new time zone, Karlsruhe. It's the same like Berlin, but it's still called Karlsruhe. And I have my daytime object, like I have my string with KHEE at the end, and it interprets correctly, okay, this is your Karlsruhe time zone, but it works the same as in Berlin. If you get a lot of data without time zone info, what you can do, you can still, in Europe, you can still have a look at the end of March, end of October, see whether there is some repeating information or missing information. You can see whether it is UTC or in a local time. If you have anything to do with solar, like solar panels, power generator or something like that, You can always have a look when is the sunrise sunset and then try to match it with your data. As I told you, this arrow and other convenient lips, they have to be based probably on the TZ data and you have no other possibility than to rely on the information that comes with this. PostgreSQL, beautiful database, works with time zones very well, but again has its own TZ data information. So if your server and your client don't work with the same version, you may get some problems. Oh, there is one time zone that is beautiful, very practical for conferences. If you call for papers and you don't have a special time when you want to finish, but you want to finish at some special time, some day, you can use the time zone anywhere on Earth. So it's anywhere on Earth, like 24, 10, anywhere on Earth, This means that until the last country in the world, in this case it's Samoa, at midnight we can still submit a proposal and it means that for us in central Europe in summer we can do it until one o'clock in the afternoon or the next day and in winter until midday, until noon. What are the best practices? Don't invent your own time zones. Don't hard-code any rules. Keep your time zones up to date and track where they are, which version you are using. Proconvert from local time to UTC as soon as possible and back to local time as late as possible. Then follow your government, what they do, and as soon as you see that they are trying to change the daylight saving time introduction or abolishment, just inform Visit IANA and your mail may just appear in those files and in such slides. If you have some local events, like we are going to meet every Monday at 10 o'clock, just store it as some form of text and then convert it to the local time as late as possible when you know, okay, there will be no change of daylight saving time or of our time zone before that date. And the best, actually, is to avoid the time zones if you can. Thank you. Thank you. Thank you very much. We have time for questions. Is there any question? Just like, what time is it? Yeah, I will bring you the microphone for the recording. Thank you for the funny talk. Could you do a talk on leap seconds next time? Leap seconds are technical. There's no politics in it. Is there any other question? okay so perfect timing so to say and thank you very much