 No one is right on time after lunch, right? No, you can suck. But there are dogs there. The dogs are on there. The dogs are there. Maybe. Well. Possibly. Hello. Thank you for being here on time, pun intended. So, and it involved a lot of time you being here. Like, I mean like planes and trains and schedules and is your calendar open for this world camp. And if you woke up on time, and if you remember to go to the token time, and I need to be on time in this time zone, not in my own time zone, which is an hour ahead. And the interesting thing about time, we don't talk about time as global cosmic concept because from that point of view, it's kind of still a bit of a mystery. So, if you say this talk was a waste of time, I can counter that from certain points of view, time does not exist. So, we talk about time in a practical sense. We talk about measurement of time. And for measurement of time to really work, we need to be on the same page about it. You need same time on your watch as it's on my watch, as it's on my computer, as it's on calendar, as it's in organizer schedule. It only works as far as we are all on the same time. And as people involved with making off-sites, we're not just consumers of time, we're also producers of time. Everything we put out there, or enable other people to put out there, generally has a time attached to it. And as all the things, it also needs to be part of the same measurement, or things start to go not so well. So, my name is Andrey Savchenko. You are more likely to know me as Rustin, WordPress circles and online. I define myself as WordPress contractor, and everyone immediately says, so is it like a free answer? I'm like, yes and no. So, my specialty is I work with other developers. I don't work with end clients. So, I don't solve people's problems. I'm not too good at that. I solve problems of people who solve people's problems. So, I am like once removed from humanity that works a little better for me. And the things I typically deal with are complex things and messy things. And a bit of a trivia, I am 1 billion seconds old, and I dealt with WordPress a little bit over 300 million seconds, and this will get finer as it goes on. And it took me a while to notice that WordPress is really not too good with time. So, we trust it to deal with time for us. This is not part of usual publishing workflow. You tell it to publish it now, or you tell it to publish it tomorrow, or you tell it to publish next noon, but you set it to next midnight, which always happens, it's guaranteed. But generally, we trust, we put a lot of trust in it to do a good job about time implicitly. And in many cases, it doesn't. And you might not have noticed it, and as I said, it took me a lot of time to notice and even more time to take it apart and figure out why of it. So, let's do a same-page check, like two questions. Does this talk actually matter for you? Had you ever changed WordPress time zone on any site you own or any site you've been involved with any time for any reason? More than half of people. So, when you do this, you break time on every post before that point. As soon as you changed WordPress time zone in WordPress settings, every post ever made on that site is now outputting incorrect time. So, this is something that might be worrisome, right? Had you ever output localized time in any way, shape, form, anywhere on WordPress site with functions like date I-18 and the date any of them? So, this is broken at least three major ways that will be covered in this talk and several more major ways that didn't make it in because they're not as easy to address. But, essentially, this process is also a very, very not good shape. So, let's go a bit back to the how we ended up with what we have from the earliest days. So, essentially, our concept of time is practical and this practicality is rooted in our solar day. Like, we're here at this moment because it's like acceptable concept of business time when the sun is up, when we're awake and no one would schedule this talk from middle of the night, right? And as people were good at resolving this. So, I went to a WordCamp last year and I looked at schedule and there was a small mistake. So, one of the workshop was scheduled for three in the morning. It says on the schedule, 3 a.m. And I'm pretty sure no one showed up at that time because as people, we are very good at putting time information in context. So, we kind of, yeah, we are grumpy about time zones, but in our daily life, we are mostly pretty good at this. And you know who is not good at it? Computer science. If you tell computer three in the morning, it will be waiting there three in the morning. It doesn't put it into the social context. It doesn't put it into solar context. Your computer or your web server doesn't care if the sun is up. Like, it can figure it out if you really make it. But that's not something that like CPU does, just out of, you know, because that's the thing to do. So, and as history of humanity progressed, even when we started to agree how to measure time, even we agreed on things like how many hours, how many minutes in the hour, it was still very fragmented. So, the time moved from being just solar to being a city time, which was might not have exactly aligned with solar time, solar noon, but it was localized to a city. And you didn't much care what time is it next city over, right? If it takes you a day to get there, you don't really care that they're like 10 minutes incorrect from you. So, not at those speeds. And for a while it went on and people had to like micro-adjust in not so often cases when they traveled. And this started to change with railroads. Because when railroads started connecting cities, the world got a lot more connected, a lot faster. And it was no longer practical to have this variance when the train goes through multiple cities in a day, and every city does its own thing, then the schedule gets a little crazy. So, way, way before the concept of time zones, there was like predating it's a concept of rail time. And countries that had got heavily connected with railroads, so this process went through in England, with rail time being established, and then process repeated itself in United States as it got covered with railroads and more territory. They had like three rail time zones established in the country. And even as concept was introduced, gradually everyone switched to it, because with increased standardization, it was increased convenience and increased reliability. We started to converge on same measure, not just in local area, but in larger and larger and larger area. And as world got more and more and more interconnected first physically and later electronically, this led to establishment of time zone, which it quite amazed us means that everyone actually agreed upon, like think about it, like what the other things that pretty much every country in the world agrees on universally. It's nearly unique that time zones were adopted that well, because it was necessity, it was necessity of time to converge on same measurement for it to be of any use to all of us. And what we have to deal with now, it led to establishment of universal coordinated time, UTC in short, and I always wondered why is it called universal coordinated time, but abbreviation is UTC. It doesn't follow the order of what its name actually is. So the story is when it was being like formulated and codified, the American and French had defied about the abbreviation, because Americans wanted to be abbreviation from English and French wanted to abbreviation from French. So they compromised on abbreviation that is neither English or French. So UTC is as an abbreviation was made up to please laser sight. And this is essentially the time that computers on those are like deepest darkest level deal with. So how do computers see time? Unix time, you might be familiar, you might be not familiar, but I would more likely to guess that at some point you saw this Unix time is a number and it's a number of seconds that had passed since midnight 1st of January 1970, and it was actually like established retroactively. So it was I think introduced in 72, but they kind of went back and decided that it's going to be a starting point. And the enormous like an obvious advantage of this number that it is global, it doesn't fluctuate with time zone. This moment of time is same here as it's on the other side of the world, as it's on the moon, as it's on the Mars or wherever our like minions made it to. It's global and not only people, but computers are in the same system. So it's called Unix time, but usually pretty much everything uses this now. Windows kind of does its own thing, but here it's most definitely ever of it and interoperable with it. So the things that define it, it's very consistent, it's storage friendly, it's one number, it's not a complicated sequence, it's there is no question is the day before the month or after, it just seconds. It's very computational friendly, it's very easy to compare to numbers. If you have two times times, it's trivial for computer to tell. So this is earlier, this is later. It doesn't need to figure out, wait, was it in the summertime? There is no summertime, it's only seconds steadily ticking forward. But it's not really human readable, like humans would not use this as is. You don't tell someone, I will call you back in 7000 seconds. So we're not worried for it, so our historical context does not smoothly translate to a giant pile of seconds. So usually the systems we do deal with need to introduce a flare of like human friendliness of being able to go smoothly, operate in what computers want, but interact with people, take inputs from people and provide people with outputs that are reasonable for humans. So in PHP, this is a daytime component which is a part of core. It's pretty large, but most of its functionality is a daytime object that represents a moment in time. And it operates internally in Unix time, and I think the modern PHP versions it started to provide a lot on operating system. So it expected, it asked the operating system what the time is, but gradually this was moved over into PHP language itself and it now provides very consistent platform for this over different operating systems. So it has range of minus 2.5 billion years to plus 2.5 billion years, which is enough for most typical use cases. And it's capable of formatting and outputting time in wide range of formats on demand as well as reading time from vibration formats. And it operates with a number of time zones which are not just offsets. So it puts time zones not just by the hour, but by location. So if you run this on a server, let's say here, which preferably properly configured, it will by default assume time zone of Europe, Berlin, which not only knows how far it's away this time is from UTC time, but it also knows things like where is it located geographically. It knows things like is it summertime in effect, because at the moment it is. And it has a historical record going backwards and forwards of all the changes. So this is like immensely more flexible than just saying plus 2 hours. I went over this, so it's based on UTC. It's very good for formatting and parsing, so for human-friendly. And one downside that it's primarily engineered to work in English language. So there are extensions that built on top of it for localization, but out of the box, English is what you get. And there is a great book about it, called Date and Time Programming, written by Derek Reddance, who is author of a rather famous Xdebug extensions for PHP. So it came out in 2009, nine years ago, but it is still too new for WordPress Core to use, because it covers up to PHP 5.3. So if it might seem dated, but on WordPress scale it's okay. So if you have a couple free evenings, I highly recommend it, because it goes over a lot of nuances that you wouldn't normally encounter. And I hear second edition is in the works, and I'm very much looking forward to that one. So let's talk about time in WordPress. So time in WordPress is on fire, and not in a good way. So the directions, the priorities of WordPress in a project put this like daytime, which I don't mean daytime in PHP, I mean it's called date slash time component of WordPress Core, which like loosely groups all the functions and all the computations and all the related core code that deal with time. So it's not in a good shape, and you know it's easy to pick on it, because it's easy to pick on things, it's easy to hint at, you know, it's universal, it makes everything, it makes you like the very smart person. But it's really kind of the history and priorities and things that made sense over a decade ago, and it all adds up to current situation, and it's unfortunate, but it's not something to pick on, it's something to face, it is something to be aware of, and it is something to fix in many cases. So daytime component in core is not even PHP 5. It's literally PHP 4 code, written before PHP 5 was even released. And it has been many parts of it, had made like this journey through time and open source over a decade long, and because of backwards compatibility commitments, they are now extremely hard to work with and extremely hard to change. So some parts had been retrofit to PHP 5, so there were like patches on top of the old code that try to provide better experience now, but because of backwards compatibility, that old code needs to keep working. So it is a building on a shaky foundation and smart people made great improvements and put effort into it, but that underlying foundation it is still bleeding through in many cases. And especially is that two main challenges is that WordPress is using custom time zone logic originally, since it would not even know that PHP 5 will eventually appear and solve these problems. So it had to write its own custom time zone logic from scratch. And that works, but not well. And WordPress uses custom internalization since PHP didn't offer it the ability to output the internal information. So custom information is this amazing range of languages that WordPress can work with. WordPress had to evolve to internationalize to take some moment in time and not just output in an English, but output in a necessary locale. And while this is certainly a huge, huge benefit and something that we need, it also comes with a price of compatibility and box and backwards compatibility and so on. And I'm getting to the scary parts. So once I was in an endless loop of fixing things over and over again, so I wrote a small library called WP Daytime which is kind of trying to be a middle ground. It's trying to make WordPress friends with PHP on this topic. And it doesn't succeed at everything, but it's a place where I dump all the scary code, all the scary fixes. So I will not be dumping a lot of code on your heads today, but you'll know where to find it if you want to or you can sleep tonight. That's your choice. So let's start with time zones. So WordPress has two not quite connected different times and options. So the old one is GMT offset and the new one is time zone string and GMT offset is offset in hours and time zone string is what PHP currently uses, the description of continent and location. So and in WordPress settings, still as of right now, you can still, if you pick a city, you're in a new mode and if you pick an offset in settings, you are in old mode. And not all things works with both modes. So new mode is trying to be backwards compatible. So if you have Berlin sets, trying to get new option will get you Berlin and trying to get the old option will get you too, which is current offset, but it doesn't work other way. If you have UTC plus two, then you won't get times on string if you ask for it. You would know where you are. And just like cherry on top, it might return integer, it might enter string. I had caused a lot of boxing because of that. So how do you do that in all cases? So you always need to prefer times on string and if you don't have access to it, you use the GMT offset and preferably for the best compatibility with PHP, if you are forced to use offset, you convert it to this format, like plus, minus, hours, minutes, and newer PHP version will understand that as times on input. Even though it's not a location, but if you give it this and say, this is the time zone to use, it will get that. Unfortunately, not in old versions. You just are stuck with things broken. And WP daytime implements this. So if there is a method to, say, get me WordPress times on whatever it is. And if it's borrowing, you get string, and if it's something called unbroken, you will get a numerical representation. And the second large broken things is date I-18N, which stands for date and internationalization. I can never pronounce it. And this is built as analog and on top of PHP date function. And the main purpose of both is take a moment of time and output it for human. And on surface, it's two very different, two very similar functions but there are a lot of difference under the hood. So date is operating in English. WordPress version operates in WordPress current locale. Date operates in PHP time zone, which WordPress will always try to reserve to UTC. So if you call a native PHP function in WordPress context, they're normally should be in UTC, but there are no guarantees that some plugin did not just go and change time zone. And some of them do that and something to be aware of that it can work on my machine, but if you're producing public code, plugins, themes, then something entirely unrelated to what you do can break time output for you. So date I-18N operates with time zone string and notably only with time zone string, it does not support GMT offset. And date operates with UNIX timestamp and date I-18N operates with what I call there is no name for it. I call it WordPress timestamp and WordPress documentation and inline documentation will tell you a big fat wise that that is a UNIX timestamp, but it is not. And the formats that you use to explain which output you want are based on date and date I-18N supports most but not all of them. So how it works, if you want to say like output me fancy output, produce me fancy output for this moment of time. So at first you provide the format which is like a huge document that describes so every letter has some meanings, this is for hours, this is for hours like 12 hour based, 24 hour based. You provide it with this format and then it will go look and oh, I know what to do with these parts and then it will go through locale and every part of format that is localizable WordPress will replace with its localized version and then it will go through time zone and it will replace time zone bits with WordPress time zone and then everything that is left will be passed to date function which makes sense on the surface you want WordPress to do what it is good at and you want date to do what it is good at but there are big inconsistencies because these two functions think in different time zones so WordPress does not think in UTC and date thinks in UTC and this process is trying to provide a single result from two bits of code that are not using time the same way and that leads to a lot of problems in practice so as I mentioned first is no GMT offset support date I18N just don't know what GMT offset is if code runs on old WordPress version or even if the WordPress version of WordPress is new but the setting is set to old mode set to UTC plus 2 it wouldn't know what to do so for Berlin it will oh I know it should be this much for this format and it will get replaced and if it's set to UTC plus 2 then it will just pass it on to date and date has no idea what GMT offset is it doesn't care it only cares that your PHP is set to UTC time zone and it will just happily put UTC time zone in and this is very interesting among developers you can tell a verness by geography so we are in Europe so if it's like one or two hours for us it's like okay it's an hour off but for some people it's 12 hours off and I see questions all the time like my time is not just a little off my time is in the wrong day because it's off by 12 hours you are likely shooting into yesterday or shooting into tomorrow so this is something to be very very aware of because this is not something you have control over you don't know you have control over your own server under best circumstances but as soon as your code is out there in the wild you don't have control over it you don't have idea of what people's settings are so then it fails with Unix timestamp so if you provide time which is for PHP functions that says just give me a timestamp from right now if you provide it to date it just works like noon UTC just fine if you provide it to date i18n then it outputs wrong result and this is like completely contrary to what documentation says because documentation is very explicit you give Unix timestamp in this function but you don't because if you do then it will output there UTC time and then it will put current time zone on top of it which has nothing in common with what that moment of time actually represents so what WordPress operates with is what I refer to as WordPress timestamp which is a sum of Unix timestamp and offset for current time zone and it's very very problematic because A it's not interoperable with Unix timestamp if you give Unix timestamp to WordPress things break if you take a timestamp out of WordPress and you miss this and you take not Unix but WordPress timestamp out of WordPress and try to pass it to different system it fails as well and on conceptual level it's like well if it worked at least but the WordPress timestamp is different everywhere the largest advantage of Unix timestamp it's global it doesn't change with time zone WordPress timestamp changes with time zone in different with different time zone settings same moment in time will lead to different WordPress timestamps and you can tell by looking it's just a number you can tell you can look at the number and guess is it a Unix timestamp is it a WordPress timestamp is it a WordPress timestamp in certain time zone so and in course there is a lot of legacy logic that kind of piles up this micro adjustments to essentially start with a lot of wrongness adds up to results that works most of the time and when core functions code date IATNN in most cases that will pass the WordPress timestamp so they will add this offset somewhere on the way and while date IATNN is code to produce output it will be called with WordPress timestamp not Unix one but if you try to reuse it in your own code and you're passing Unix timestamp in it you're producing broken result so and there are a lot of very varied formats most of them work with date IATNN but some don't and the two that most in my experience most often get people are C and R because there are so called shorthand formats so when you tell it give me date RFC3339 the date RFC blah blah blah is a PHP constant so it actually contains a string with complete format so input it sees is just a string and it produces output letter by letter but C is not a constant C is implemented on a level on a PHP core level so when you give C to PHP it all you mean you actually mean that one thing but WordPress doesn't have access to it and when you give C to WordPress WordPress goes I didn't know what to do with this like let date handle it and when date handle is we get same problems we get incorrect time zone output because WordPress didn't not process time zone WordPress didn't know there is a time zone in C because it's not aware of it and we get lack of localization because again anything and everything about WordPress vocaliate did not apply it doesn't know that there is something inside of an R that needs to be localized so there is a as I mentioned there is a GitHub repository with a pile of very scary code that fixes this to a reasonable extent and the way I approached it is extending PHP datum objects with things that kind of a layer what I call my layer of sanity around WordPress problems so you can get WordPress time zone and you can output using WordPress logic but accounting for all the problems so it will compensate for time zones differences it will compensate for format differences it will apply WordPress localization and important benefits that it kind of get for free you can change time zone so in WordPress you can only ever output in current time zone of the block of the site which is something not something you always want because if you're like geographic located in one country but you're producing a site for audience in a different country then your time zone might make no no sense to them on the front end so this allows to adjust on the fly what your where your output is placed in regards to time zone so and this is just kind of so far had been things that happen on the fly when we provide input and output but WordPress also stores times because naturally if we make a post we wanted to come with a time attach this was created at that time this was modified at that time so who sees a problem with this it doesn't know time zone when you create a post in WordPress there is no time zone information attached you're storing GMT time which WordPress does store but does not actually use pretty much ever you need to go and look for it and ask for it if you want to operate with it and there is like sometimes stored without time zone and let's say like you came here from London anyone from London in the room no so you say you came here from London and your notebook is in front of you sent to London time zone and you created a post and it says like 1pm London time and everything is good for so far but then you say wait but I'm in Berlin right now and I'm live vlogging this and I want time to be accurate to Germany and as soon as you change time zone WordPress site your output breaks because the time is still from London the time is when that post was met in London but time zone is now Berlin time zone so WordPress combines time information for post from two different sources without any meaningful connection between them it always seems that wherever whenever post was made that this is in the current time zone setting and since the setting can be freely changed every changed discards that information and for a site with a lot of history there might have been multiple changes over time and you completely lose track when like this set of posts was met in that time zone in that time zone you try to for any reason to give an accurate historical record and you go by post date then you are out of luck because that information is just broken so the logic if you want to produce output that is not guaranteed but a little more reliable what you need to do you try to get post date GMT from database and unfortunately WordPress does not guarantee that it is there so if you look at it it will usually be there but there is no guarantee so if you set out to it or if code is of a little shoddy quality you can create posts that won't have GMT time attached so if you are out of luck if that information is not available then you get post date and hope that it's still the same time zone and then you get WordPress time zone and then you either combine the two or you take the UTC time and move it to desired time zone and then you output it to desired format again, bioscary code on GitHub that does this it will say scrape from post and you give it post object and it will do its utmost best as far as it can that the time is correct and even when there is discrepancy between time zones the post was made and correct time zone it will try to go around through GMT time so you still end up with correct results so to sum it up it's unfortunate reality of current situation that WordPress gets both time storage and output very wrong it's not really a question if you're affected by it because you are, believe me you are affected 10 times if you produce any public code that touches time in any way because as soon as you don't see the settings and you can check for the context you just don't know anymore you hope that it works and in the best case it does in case that nothing had changed its settings nothing had changed settings since the post was made and no plugin or ZIM had changed time zone on the file under ideal circumstances WordPress core will produce the correct output but as soon as any element is out of sync the output will be wrong so like to-dos or best practices or sanity or calls it what you will always read and use UTC time because that's what computers understand always convert if you need to store something convert to UTC time if you need to output something convert from UTC time anything else will get you in trouble at some point bins are done, there are broke things fix things, broke things again still probably broken things that I wrote out there so save time stamp ideally or UTC time if you absolutely need to store time zone with time use I recommend using RFC3339 which is very specific format which is very hard to mess with because you can't change it there is like a little more known ISO 8601 you might have heard references but it's very wide format so time zone is optional date part is optional, time part is optional there are a lot of ways to write it that will be valid but not have complete information with RFC3339 you are forced to use very specific format that has complete information use date time, PHP's date time to operate time to do any computations to do any comparisons never just go I will like compare like this second this like hour with that hour because the time zones will get you the daylight saving time will get you so there is a bug in WordPress that at certain time you cannot publish posts because time changes, time jumps back and certain moments in time happen more than once at night so you are trying to publish posts at 1.30 am which happens twice at night and WordPress will tell you oh but that in the future it hadn't happened yet so you might want to schedule posts not publish it and it will literally won't allow you to publish posts until you reach 2.00 am and if you are interested in code side of it and I don't say that you need to drop this into everything that touches time I drop into everything that touches time now but that's my personal toy but that is as far as I got in core in addressing this and unfortunately the big challenge of fixing this in core is that it can't be done piece by piece so WordPress is improved in most hours by incremental process there is a bug reported time passes someone writes a patch time passes parts get merged and this gradual improvement in many hours leads to much better code quality and reliability and functionality but the problem with time daytime components specifically it cannot be fixed piece by piece because as soon as you are trying to mess with one corner of it you are because of those adjustments of those timestamp adjustments of those old assumptions of difference in settings you produce a cascade of bugs through the system so whenever it happens if it happens the only viable way is to fix it in bulk you would essentially need to rewrite in parallel a new daytime component and at certain point of time you would need to swap it completely which is a big challenge and so far there is no technical or political will to get it in shape and I encourage you to participate there is a great selection of bugs on Drag WordPress org for discussion and for urging can we please get nice things as the rest of PHP world and that's all for me time questions I'm like 45, 44 sharp so the main in regards to PHP version the main hold up is understanding of how to deal with numeric time zone because it is hard to go from the plus to hours to wider context you can't inflect this information you can take two hours and guess that this is Europe Berlin you don't have sufficient information you can go backwards you can start with Europe Berlin and narrow it down to two hours and as I covered in the talk being able to tell PHP this is like plus two hours and have it work is PHP 5.5 plus so PHP 5.5.10 precisely if I remember and I would guess it is possible to work around this in horrible and inconvenient ways but PHP 5.5 is what I consider the minimum to do anything meaningful with daytime in modern PHP this is the very minimum version that has just necessary not like nice to have necessary functionality to work with dating time in modern PHP code 5.5.10 no way to fix it on 5.2 externally that just not within a technical possibility so there was a great question at WordPress Stock Exchange so someone wanted to use WordPress to make to publish a historical record they wanted to use custom post types with dates that are not set into the present or anywhere near present they wanted to go back hundreds of years ago and they were having a lot of troubles with this and I was like I have nothing to do on Saturday I can answer this and so it took me six hours to put that answer together because there are essentially multiple limitations on how far back and how far forward you can go with WordPress so there are limitations on PHP level that are more relaxed now as I mentioned give or take two billion years on PHP level it's mostly fine there are limitations on SQL level so you might provide correct input but SQL wouldn't know how to deal with it there are limitations on WordPress level with validation because some dates that you will try to provide into WordPress it will go this does not look real I don't want to accept this there are limitations on JavaScript level because when you are providing a date in admin it also has some limits I don't remember the exact numbers so that date range so my final answer was that date range that WordPress reasonably operates in is 1917 to 2038 so this is a range that everything just works as soon as you try to go backwards things start to fall apart and if you go forwards you kind of hope it works but like MySQL behavior gets uncertain at that point like current versions of MySQL they are spec for datetime field does not cover I think beyond 9999 so four digits for year and there are some other limitations so if you are doing like more interesting more wide range of time you need to do this yourself you need to save it as a custom field preferably as a timestamp and then you know have fun with calendars and all of that that's a special level of interesting they don't I'm not sure about MySQL I know that Unix timestamp does not account for lip seconds so for the context we all know about lip days every four years we get lip days and there are sort of we have a formula in advance we can go forward and we know when lip day will happen and we can go backwards and we know when lip day did happen but there are also smaller fluctuations in Earth rotation and they are not predictable because it's a ball of stone flying through space it's not a very precise process so at time scientists measure this so I've like dug into a lot of trivia on Wikipedia by preparing this talk so you know we went from looking at the sun and knowing it's noon we went to a network of 50 plus atomic clocks all over the Earth and we think average for timekeeping because with only one clock you get side effects from cavitation so things escalated and how we measure our frame of reference expanded from standing on the planet there are stars around and we can point at them to triangulating our position in space of the pulsars of radio signals from radio emanating cosmic objects so things like escalated to Earth and now and then they measurement from specific measurement they need to add a second so there is a theoretically they might need to remove a second that hadn't happened before but they sometimes now and then they need to add a second so the time we usually deal with UNIX time UTC time ignores it like they just decided this would be too much so for civil purposes lip seconds are generally ignored and if I'm not mistaken the current drift is 27 seconds so time we use in our daily life differs from like scientific, astronomical measured time by about 20 seconds and it keeps increasing thank you for being here