Understanding Time, Date and Calendars: Live with the R&D Team

Nick Larvier from Wolfram R&D explains how computers handle time, dates, and calendars. He covers UNIX time, different calendar systems like Gregorian and Julian, lunar versus solar calendars, time zones, and why leap seconds exist. The talk includes live code examples and a Q&A.
Questions this video answers
Nick Laravier, kernel developer at Wolfram Research (focus: dates, times, dimensional data).
Wednesday, March 8, 2023.
36 leap seconds.
Chapters
Foreign. We've got a couple minutes left until we hit 11 o' clock central time. So wait just a couple of minutes. But in the meantime, my name is Nick Laravier. I am a kernel developer here at Wolfram Research, and my primary focus in development is on some of our dimensional data frameworks, that being dates, times as well as physical quantities. And for roughly the next hour, you'll be getting a short tour of time dates, calendars and related topics, the general conceptual overview of them, as well as how they are actually represented inside the Wolfram language, and some of the trickier aspects of working with dates and times. Okay, so we are right at 11 o', clock, which will give us a nice segue into our first area of conversation, which is looking at time. So we'll start off with a pretty basic question. What time is it? If you were to ask your computer what time it is, it would likely report something that we call UNIX time here and would say that it is the 1,678,000,000, 201,000,000,000, 678,000,000th, 294th and 874th second since the UNIX epoch, which is very nice for computers, it's not particularly helpful for human beings. And have here a nice little breakdown of what time it currently is in a handful of different time zones, which we'll get to in a little bit. But the general concept of time is something I kind of want to spend just a second talking about what we actually mean when we talk about time. So time as we are generally familiar with it, is a basic concept my 5 year old and 3 year old understand. But what it actually means is kind of difficult to pin down in terms of how it exists, both philosophically and how it exists in physics. So to boil it down to the most general terms we can, time is a continuous sequence of events that happen in an apparently irreversible succession from past through the present into the future. So basically it is a sequence of events that happen continuously without interruption. And we can't go backwards in terms of how time is formally defined. We generally refer to time as being built up in units of measure, either through physical quantities or through calendar systems, which we'll talk about in just a little bit. The International System of Units, which handles SI unit designations, says that a time is defined that time is fundamentally based on a second, and a second is defined as a certain number of ticks of a cesium clock. Generally, throughout human history, we've defined time as being broken up into cycles of years or days or Months, and we have subdivisions within there. So a day is 24 hours, is 60 minutes, is 60 seconds, and so on and so forth. But as we will get into in a little bit, our actual notion of time is a little more complicated. So if we want to look at, you know, just a. The way a computer typically understands time is that it is just a fixed number of seconds since an epoch, which is a start date for UNIX time and UNIX systems and most computer systems that would be January 1, 1970, at GMT at midnight. And so your computer typically reports time as a number of seconds or milliseconds since that time period. We also have a related notion of time that I'm going to periodically check back in on, which is sidereal time, which is the way that we measure time in terms of an angle relative to a distant point in space. And so we have a function, Wolfram language, called sidereal time, that returns a angle of right ascension. We are 22 hours, 16 minutes and 1819 seconds into sidereal time. When we hit true noon, that will basically roll over. Sidereal time is based on your specific location as well. Okay, so those are two forms of time that we probably aren't particularly used to dealing with on a day to day basis. A nice little graphic here that shows how our notion of time and our ability to represent and measure time has changed throughout human history. So, you know, when we first invented water clocks, we were able to half time accurately measured down to roughly a hundredth of a second or a tenth of a second. As time has progressed, we've gotten better inventions in terms of wheel clocks or pendulum clocks. We eventually created quartz clocks. And then atomic clocks are the general basis of how we measure time these days. So that's how we handle the physical quantity of time. There's a number of seconds. We basically measure that from some start point and they continue to go onward effectively uninterrupted. So then what does it mean when we start talking about dates? So we'll start with a simple. What is today's date? Well, Today is Wednesday, March 8, 2023. At least if you're using a Gregorian calendar and you happen to be this side of the International Date Line right now. But a date is basically a measure that is constructed of time for human understanding. So again, if I say it's Wednesday, March 8, 2023, it's much more intelligible to someone familiar with how our normal calendars work than saying we are on the 1 billionth, not 648,000 or 648 millionth second since Unix epoch. But what day to day is really depends on the calendar system you're using. So if you. The most widely used calendar system, civil calendar system in the world, is the Gregorian calendar, which is very closely related to another calendar called the Julian calendar. But if we look at our Julian calendar, today would actually be February 23rd. And the only real difference between the Julian calendar and the Gregorian calendar is how it handles the notion of leap years. So colloquially we say that a leap year happens every four years. That's actually only true on the Julian calendar. For the Gregorian calendar we have a leap year every four years, except for every hundred years, except for every 400 years. And so there's a variation on a 400 year Gregorian cycle where we actually have three fewer leap days than we do, or three fewer leap years. So three fewer days than on the same 400 year Julian cycle. So that is the difference in time here is basically the cascading effect of those three different notions of when a leap year is between the Julian and Gregorian calendar. There are many different calendar systems in the world. Some of them are civil, some of them are religious, some of them are based on astronomical observations. And so when you say what is today's date? You're really referencing some frame of human understanding of time. So if you were in Japan, they both use a Gregorian calendar typically, but also a Japanese Gengo calendar, which is a regnal calendar. So instead of saying it's February, it's March 8, 2023, they would say that it is Sangetsu. So March 8. But it is the fifth year of the Reiwa era. And every time there is a new imperial monarch in charge of promoted in Japan, the era rolls over, which we'll dig into in a little bit if a nice selection of different calendar systems to figure out what actually the the current day is. This notebook will be available later and you can feel free to play around with it. Some systems use a single number to represent the current date or time. So this is the current Julian date is a number of days since the Julian epoch, not to be confused with the Julian calendar, which is a different concept that also it is based on a different epoch. We also have Julian year and a whole slew of different calendars that we can dig into a little bit later if people have questions. So what day it is, what the date is, that really depends on what your reference point is in terms of the calendar you're thinking about. So to boil this down, what are dates? A date is a reference to a particular Instance of time. Generally, when we're talking about dates, we're talking about days within a calendar system. Calendar systems are ways to project time into a unit of measure that's easier for people to understand than just a number of seconds that we're counting from some ancient epoch. And it allows you to uniquely identify a date. So since dates are based on calendars, what exactly are calendars familiar with? Looking at a calendar on a day to day basis. But where does this notion of time actually come from? So a calendar is a system of organizing dates and times into periods of time, usually consisting of multiple elements like days, months and or years. What types of calendars are there? There are a whole bunch of calendars. So within the Wolfram language, we have a function called calendar data that can report information about different date calendars. These are all of the built in calendars that the Wolfram language knows about, is able to do conversions for, and can provide information. One set of calendars you won't see represented here are what I'll call observational calendars. These are formal calendars that are typically based on either solar or lunar cycles, where the actual representation and timekeeping is left to some person of authority to go outside and look at whatever celestial body is used as a reference point and say, okay, this is officially a new moon based on looking at the moon. And so our timekeeping will mark this as the beginning of a new month. Those are generally not easy to represent computationally. They're mostly used historically. But they are calendars that do exist. And many of the modern calendars we have started out as observational calendars that were then formalized into different systems. I mentioned a little bit ago about regnal calendars. These are calendars associated with either dynasties or rulers or emperors of one kind or another. So as I mentioned, if you look at the current date on the Japanese Gengo calendar, we are in the fifth year of the Reiwa era. If we were to go backwards and do a conversion of a date a few years ago, we did a date that is in 2011, and we wanted to convert to the Japanese calendar, we would be in a different era during the Heisei era. So there is a large collection. If we look at, we look at our calendar data for the Japanese calendar, and we look at our calendar. Granularity quantities, which are basically the, our granularity ranges, which are the possible specifications. We have this large collection here of different eras that exist throughout the Japanese calendar that correspond to the regnal periods of different emperors in Japan. So we're currently in Reiwa, we had Heisei and Showa, Taisho, Meiji, on and on, back to early feudal periods in Japan. And the Japanese calendar has additional complications that I won't get into here. Like the Nambokcho period was a period where there were two imperial courts. And so how do you refer to the era? There are two different timekeeping systems. As with most things in human history and human philosophy, politics come into play. And so the point of view of history often skews the way that we understand time. So for the more more recognizable calendars, we generally divide them into two camps to either arithmetic calendars or astronomical calendars. Here again, in the Wolfram language, we can use calendar data to extract information and say which calendars are arithmetic. That means there are fixed arithmetic rules for the schedule at which certain events happen. So our good old friend, the Gregorian calendar is defined as an arithmetic calendar. We have rules about when the leap years happen, how long each given month is, how many hours are in a day, etc. Astronomical calendars, on the other hand, are typically based on actual astronomical events. And so we have variations here where the Chinese lunar calendar is based on the actual cycles of the Moon. All of these calendars involve some level of astronomical calculations that are needed to actually pull back in information about what the lunar cycles are that solar cycles, these also typically have an extra property associated with them that will say where your location of observation is. So were I to take calendar data and ask for the properties of the astronomical Persian calendar, you could see that we have some basic parameters, like there is not a year zero, the start of day is at midnight, and the location of observation for astronomical events is Tehran. Any of the astronomical calendars can be modified to use a different location and that will change what day it is at any given point. Within both astronomical and arithmetic calendars, there are also subdivisions in terms of whether a calendar is a solar calendar, a lunar calendar, or a lunar solar calendar. Basically, a solar calendar is fundamentally based on the cycles of a solar year. So the main unit of measure is how long it takes the Earth to rotate around the Sun. A lunar calendar is based on a monthly lunar cycle rather than a solar cycle, and a lunar solar calendar is a combination of the two. So the years are based on a circuit around the sun, and the months are based on a full rotation of the Moon around the Earth. But those two cycles don't actually align very well. And so lunar solar calendars typically have some sort of periodic leap month or day to realign the two calendars Together. So, for example, the Chinese lunar calendar is a lunar solar calendar. And periodically within a given cycle, you will have multiple instances of a month. So if we go back to 1648, we can see that the 20th day of the fourth month would have been Tuesday, May 12th on the Gregorian calendar. But there is a leap variance which indicates there is a repeated month that actually happened after the fourth month that was also the fourth month, because there were two lunar cycles within the period that would normally be the fourth month of a solar cycle. And so we use a leap variant head to denote the fact that even though this is the fourth month, it's the second instant of the fourth month. And so that would actually correspond to being in June on the Gregorian calendar. And for particularly fun case, if you look at the modern Hindu Lunisolar calendar, there can be both leap months and leap days. And there are periodically months that do not exist and days that do not exist because of that misalignment of solar cycle and lunar cycle. So rotation of the Earth around the sun is about 365 days, about 365 and a quarter days. Rotation of the Moon around the earth is about 29 and a half days. And those two don't mesh in a way that's super convenient for calendar systems. So you will have repeated months in Lunisolar calendars periodically. So since calendars are built out of granular units like years, months and days, what actually are those calendar granularities? And so when we refer to our granularity in the Wolfram language, we're talking about the component units of time that create a calendar. So within a Gregorian framework, we think of years, months, and days. So what exactly is a year we talked about? Solar calendars are built on the motion of the Earth around the Sun. There are two primary definitions of what a year is. A tropical year, which is the average amount of time it takes to have the Earth rotate around the sun, and a sidereal year, which is the average amount of time it takes the Earth to rotate around the sun, not referencing the sun as the start point, but referencing a distant point in space. There are lots of different versions of this, however. So here's a small collection of different units that correspond to years and their variation. So 365 and a quarter days in a Julian year, because a Julian leap year happens every four years, it is slightly fewer days in a Gregorian year because of that variation that every hundred years we don't have a leap day, but every 400 years we do leap years. 366 days. A sidereal year is ever so slightly longer than a non leap year, but shorter than a leap year. A tropical year is ever so slightly shorter than a sidereal year. And the reason for that is that what we refer to as a tropical year is basically our average. If you look at a 400 year cycle or so of how long it takes the Earth to rotate around the sun we call a common year, or just a year, is 365 days defined for its civic utility. But you can see it's ever so slightly less than the time it takes to rotate around the sun, and the leap year is more than the time it takes around there. So we intersperse common years and leap years together, and we average out to about how long it takes to rotate around the Sun. But the difference with the sidereal year is that because the sun is the Earth is rotating around the sun, when we hit a fixed point referencing the sun, we're actually slightly oversteering what would be a full rotation of the Earth itself. And so a sidereal measure of time is referencing a distant star in space, where the rotation of the Earth around a solar body is not creating as much skew as we would get otherwise. So a mean Solar day is 24 hours, but a sidereal day, because we're referencing that, that distant point is actually a few minutes and seconds less in terms of angular rotation versus the Sun. So a month we're all familiar with is 1 12th of a year. But a month is generally based around lunar cycles. And so our notion of months in a Gregorian calendar is somewhat arbitrary. You know, we know it takes about 29 days for the Moon to rotate around the Earth, 29 and a half days. But most of our months are 31 days, but some of them are 30 days, and one of them is 28 days, but sometimes 29 days. And because the main measure for a Gregorian calendar is a solar cycle, we're not super worried about that disconnect between how long a month is and how long a lunar cycle is. But for lunar calendars, it's very important. Generally, a month starts with a new Moon or a full Moon, and so those periods are shorter. Here again, when we think about our conventional notion of a month, the formal definition in terms of SI units is that a month is 1/12 of a year, and a year is 365 days. And so a month is 30.41 days, which is about one day longer than a lunar cycle. It's slightly shorter or it's slightly longer. For Gregorian Months, because of the variation in terms of a Gregorian year, is slightly longer than 365 days. Synodic Month is basically our average length for a full lunar cycle. Tropical months and sidereal months, again, are based on different frames of reference. A tropical month is looking at the average amount over a full Gregorian cycle, and a sidereal month is looking at distant point in space. And the synodic month is another name for lunar month. So that is this is effectively the real average time it takes for a lunar cycle to run. So most lunar or lunar solar calendars have a 29 or 30 day month for our next unit measure, a day, we're used to a day being one full rotation of the Earth relative to the sun, 24 hours, 144 minutes, 86,400 seconds. But again, there's variation about what you're actually referring to for the rotation. So day is a fixed number of seconds. If we're referencing a point, a distant point in space, it's fewer seconds because again, the rotation of the Earth around the sun means that our reference point to the sun is also moving. And so it takes slightly longer than it would relative to a distant point in space. And lunar days are also a little bit longer because they're a fraction given month. So the relationship between sidereal days and days is effectively what our tropical years are created out of. So that's again, the average length of a year over a long enough period of time is that it's 365 and about a quarter days, but a little bit less a day. The definition of a day also implicitly has a start time, a given day, a given calendar may choose a different time for a day to start. So if you're using astronomical observations, midnight's kind of a bad time to figure out when a day starts because you generally don't have any reference to the Sun. And for lunar calendars, you generally want to be able to see the Moon. You may not necessarily be able to see it from a given observation location. And so throughout time and throughout cultures, we've picked different points of time to decide when a day is going to start. So a traditional Hebrew calendar, the day starts at midnight, it starts at sunset, whereas within the Gregorian calendar, we start at midnight. Again, we're working with arithmetic. We don't need to see exactly when the the sun falls below the horizon. Some calendars also begin at sunset and so or at sunrise. All of this information is also available inside our calendar data. So if we look at a Gregorian calendar, we can say our day starts at midnight. The Hindu solar calendar generally begins at sunrise. The these form that's presented here is also usable within our date framework in Wolfram language. So if I say I want a date object for now, but I want the calendar type here to be a day that starts at sunset instead, we can see that. Our calendar type is set to be beginning at sunrise and sunset. Our reference point for how far we are into the day will actually be different. So if the day started at sunrise, we're only five hours into the day. Currently, the day starts at sunset. Then we are farther along than we are with a day beginning at midnight can also have this is next noon. If the day begins at noon, then we are about 20 or about 30 minutes away from the day rolling over. So all of these parameters exist within the default calendars, but they're also things that could be modified. So a traditional Gregorian calendar does not have a year zero, but some calendar specifications may want a year zero. So if you move far enough back in time, whether or not the year before 1 CE is 0 or minus 1 can make an impact on your record keeping. So these parameterized calendars, as we call them, can be very useful. And again, any of the Lunisolar or solar calendars may use a location of observation. You can change that however you want to. So, yeah, a Julian date is a, an instance of a calendar where the day begins at noon. Right. So how does this all impact real day to day arithmetic and operations with date? So we'll start with a pretty basic question. What is the date one month after January 30th? The answer is it depends on how you're doing arithmetic and what calendar you're using. So if we were in to ask that question to the Wolfram language right now, and we said we have January 30th of this year, we add one month, it would say, oh, it's February 28th. But if we think about it, wouldn't that be N number of seconds after January 30th? Shouldn't that be February 30th? But that day doesn't exist. So does that mean we, we go to the next day after that and say, oh, it's March 1st or May, since there's no 29th this year either, maybe we want it to be March 2nd or, yeah, March 2nd. And so this human notion of time has a lot of caveats because we're basing things on imperfect and irregular cycles. So again, the rotation of the Earth around the sun varies over time. The rotation of the Earth on its axis varies over time. And the rotation of the moon around the Earth also varies, so it changes over history. And it also fluctuates day to day, which we'll get into in just a little bit when we talk about time systems. So now that we have these abstractions for human understanding and timekeeping, we need to figure out how to deal with the fact that those irregularities cause problems when we're doing arithmetic. And so within date calculations, there's basically two camps of how you do arithmetic. Continuous arithmetic uses fixed unit steps, which says effectively, that a month is always going to be 2,682,000 seconds. And so if you add a month to Today, you get April 7th at 10:00am because this is, again, a month is defined as 1/12 of a year. A year is 365 days. And so we get an odd number of hours because a month doesn't cleanly divide into days. This is how SI units, a month, are defined. This is the formalized framework that exists inside quantity. So si, as I have here, if I say I want to convert one month into seconds, I get 2,682,000 seconds. This doesn't really cleanly map to how people typically think about doing arithmetic with dates. If I say I want a month from now, it's the 8th, so it should be April 8th instead of April 7th at 10am and for computers working with everything in seconds, everything has a fixed fundamental definition that's really easy and convenient, but it just does not map well to human understandings of time and how things have been constructed historically. So our second main camp of how arithmetic works, and by far the most common when working with things like financial calculations or historical events, is to use discrete arithmetic, which is basically that there are discrete units of time that move in steps. They may be irregular. How you do arithmetic depends on where you are in time. And so when we take something like February 30th, we need to be able to resolve that somehow. So one method is to just keep adding days after the last one and say, okay, the 30th day of February is actually the second day of March, because there are only 28 days in February, and we move two days forward. This is what we would call a rolling method. And within the Wolfram language, we have a method that can be used when doing date arithmetic. And there are four different potential options, which I'll run over here. When you encounter a gap, you can either roll forward, which means skip over any gaps of dates that don't exist, and stop on the next valid date, roll Backward is the opposite. Anytime there's a gap, go back to the last date that is valid and rollover is act as if the gap doesn't exist and continue incrementing onward. So if we take that original problem and say I have January 30th, I add one month. If my rolling method is to roll forward, I go to the next date which is March 1st. If it's roll backward, I go to the last existing date which is March 28th. And if I roll over, then I go to the next existing date and continue incrementing from there. So we can see there's not a for this entire three day gap that exists in rolling forward, we end up on the same date. Rolling backward, we end up on the same date. Rolling over, we continue to increment and then we actually reset once we get to the next existing date. So all of these so we can again tackle our original problem and say what is one January 31st plus one month? If we use our rolling methods, we will get different results each time. Sorry, continuous case here. I'm truncating down just to the day for simplicity's sake, but we get three different answers for four different methods of arithmetic depending on how we want to handle those gaps. So there was a question in chat. I'll kind of be glancing back and forth with questions here, but there was a question about is there construction of human compatible notion of time with perfect cycles and or minimal caveats. So one of my favorite instances of a well thought out calendar system that people just didn't jump onto was the Newtonian calendar. So Sir Isaac Newton was part of a regulatory body in England when the debate was going on about people jumping from Julian calendar to Gregorian calendar. So anyone who works with historical dates knows that when we started keeping time with civil calendars that use a 12 month cycle that we're used to, we started with the Julian calendar, but eventually people realized that was poorly aligned with solar cycles and the Gregorian calendar was proposed. Newton actually proposed another calendar that was closely related to the Gregorian calendar, but had a slight variation in how it handles leap days within leap year cycles so that it would be accurate over longer time. So if I were to say I want to calendar convert today to the Newtonian calendar, we still get Wednesday March 8th because the rules for one second my camera is going a little silly here. I'm just going to stop it for one second and start again. See Right. Hopefully that is all showing up okay. Yep, looks like it's doing good. But if we look at a far future Date, Say I have a date object and say, I want this to be 30,000 year, the first day of the first month of 30,000 years from now. We can see that this is actually the 10th day of January, because the way the Newtonian calendar works is that there are, there's the every four years, except for every hundred years, except for every 400 years, but every few thousand years there will be a double leap day, which will, over a longer period of time, be more accurate to solar cycles. People have also tried to do things like converting the world calendar is a calendar that was proposed and never actually adopted that says today would be March 6. Its intention was to divide the year into clean sub intervals so that each quarter has the same number of days and each day always happens on the same day of the week for any given year. So March 6th will always be a Wednesday on the world calendar, regardless of what year it is, rather than on the Gregorian calendar. Basically every year you will be one day of the week later than you were the previous year, except on leap years you will be two days farther ahead. So it's Wednesday, March 8th this year. Next year it would be Thursday, March 8th, except it's a leap year and so there was an extra day, and so it'll actually be Friday, March 8th of 2024. There is no perfect calendar system. None of them are inherently better than the others, but they all have trade offs. The more complicated the rules are, the more difficult it is for people to understand. And as we'll get into in just another couple of slides, even if you have something that is perfectly suited to arithmetic and has no variation, solar cycles and lunar cycles change over time. So the rotation of the Earth is generally slowing down a little bit, but sometimes it speeds up. And the Earth's rotation around the sun is slowing down. The Moon's rotation around the Earth is also slowing down. All of those kind of play havoc with timekeeping when we're basing things on celestial observations or observations within the solar system. So the next big can of worms with dates is time zones. We say, what time is it? It depends where you are in the world. What are time zones? Time zones are basically designated areas that observe uniform standard time. So they are generally defined by boundaries between countries or within administrative regions or subdivisions of a given country, rather than strictly following longitude. So a long time ago, you basically would say whatever time it is is relative to solar noon of your current location. That's the time a sundial gives. That's basically what you're getting with sidereal Time, but it's not super easy. Once you had railroads and people could move between locations relatively quickly, it created problems for timekeeping that involved local observations. And so we typically think of the United States as having four time zones. We have Eastern, Central, Mountain and Pacific. It's also Hawaii time and also time in Alaska. But actually there are 29 different time zones within the United States. And that's because those geographic regions have historically changed back and forth. So let's run here. But within the United States, you can see that we have a large block that is Eastern time, a large block that is Central time, Mountain and Pacific time. But we have these small little zones that are different. If we make this even bigger here and see that there are a couple of counties in Indiana which are have their own coloration here, because what they have done is they've switched back and forth between observing Eastern time, observing Central time, observing Daylight Saving Time, not observing Daylight Saving Time. And these time zone collections have to keep track of all those rules, because if we want to convert back from a given point in time now to a historical point, we need to know when those time zones changed. So in simple terms, there are two primary kinds of time zones. There are numeric time zones. So if you evaluate system time zone in Wolfram language, it will give you a number of hours. You are offset from Greenwich Mean Time or gmt. Small asterisks here of. We'll talk about time systems on the next slide. And a time zone offset is basically a fixed amount of time you are offset from gmt. It does not change over time. This is nice and easy for computers. It says, okay, you are this many seconds off from gmt, so I can account for it correctly. That doesn't handle Daylight saving Time because in a, in what we consider Central Time in the United States, sometimes we are GMT -6, sometimes we are GMT -5. It changes over time and it changes throughout the year. Thus we get time zones that are either referred to as named time zones or Internet time zones. These are a collection of rules about how time zone offsets are handled for a given location. And fortunately for anyone working with computers, IANA or the Internet Assignment Number Authority, maintains a database of geographic time zones that I have a link to here that collects all of these rules and all of the changes and updates them throughout the year that says, ok, if I have, if I look at my time zone entity, this is the time zone my computer uses to look up in the database when time zone transitions happen. So if I look at my current GMT offset. I am 6 hours behind GMT. If I look what it will be at the beginning of April, it will be 5 hours behind GMT. If I go far back in the database, before central time was standardized, I will get my local mean solar time, which is just between just a little bit less than 6 hours behind GMT. And so we also have the ability to look up time zones. So you may not know that America Chicago is the name for Central Standard Time, at least for most of the United States. We have a local time zone function that allows you to input any location and we will look up what the time zone is there. You can also use these location entities or even just a geoposition to say, what time zone is this supposed to be? So at this given geoposition, we are just outside Sydney, Australia, so it is using Australian Eastern Standard Time. Our last big can of worms when it comes to dates and times are time systems. So I alluded to these briefly, but what are time systems? A time system is basically a system or a specification for how you measure time and how you figure out what the current point in time is. So if you are familiar with time systems, you are likely familiar with the concept of leap seconds. Leap seconds are something that exists within Universal Coordinated Time, which is abbreviated as utc. The general way that computers keep track of time again is just counting one second after another forever and ever and ever onward. That timekeeping system is nice for computers, but it again doesn't align with solar cycles. And so we have different time systems that figure out what time it is at a given point and how we measure time. UTC is the only time system that involves leap seconds with the asterisk that smeared. UTC is a variant of UTC that I'll talk about, but it is generally what civil calendars are based on. So our simplest measure of time is International Atomic Time, or tie. It is a average of cesium clock spread throughout the world, keeping track of one second following another. It does not pay any attention to variations in the Earth's rotation beyond the fact that relativity impacts the way that time is tracked. That's why it's an average of atomic clocks spread across the globe, because gravitational variations will impact the way that time actually flows, even on a body as small as the Earth. But effectively, just one second counts after another on tie. UTC is a attempt to realign TIE with observed solar time. And so UTC is TI plus a number of leap seconds that get added in to effectively correct for the fact the Earth's rotation varies and the gravitational field varies. So The Earth spins faster sometimes and it also spins slower sometimes. A little bit of history. UTC was first introduced in the late 1950s, 1960s, and originally it was an attempt was made to keep it very, very close to the Earth's actual rotation, which we would call UT1, which is looking at the actual gravitational field of the Earth and the actual rotation of the Earth and tracking how time flows. So there were many, many fractions of seconds added or subtracted to try and keep this alignment very tight. But that was basically a nightmare for any civil calendar, anyone trying to keep track of time realistically. So in 1972, UTC specification was updated only to add whole leap seconds as needed to keep within 1 second of UT1. So basically, as the Earth's rotation slowed down enough or sped up enough, we got close enough to being 1 second off from actual UT1 or universal time and a leap second would get added in and we'd basically correct. So we get this not quite sinoidal form here where we have harsh corrections here that fix in and recalibrate us to the Earth's rotation. So if we look here, there have been 36 leap seconds added since UTC has been invented. And we had a smooth curve where we were adding small fractions of a second and then the stepwise function effectively to keep correction between UTC and UT1 within 1 second. Have some data here if you want to plug in and look at geo orientation data will actually show the Earth's rotation. I won't dig into this example too much, but you can see basically the upper and lower boundary of when leap seconds are added in throughout time. And currently the Earth's rotation is actually speeding up and we're relatively close to getting to a point where we'd actually have to remove a leap second, which in about 20 years will not be a problem because the international body that regulates UTC has decided we're no longer going to maintain leap seconds. Going on to the future, they're complicated, they create some problems. But because specifically objections from the Russian delegation, we're still going to have leap seconds Until, I believe, 2033, don't quote me on that particular date. But after that point, leap seconds will no longer be added. If we have a major correction in the Earth's rotation that's needed to keep UTC and UT1 aligned, we'll have leap minutes eventually, probably not for about 300 years, but that will be a whole new can of worms. So just a quick exercise here showing the difference in how time is kept between UTC and International Atomic Time is that for this period, the last time a leap second was added was at the end of 2016, the last second of the last minute of the last day. In gmt. We can see that Ty continues counting up one second at a time without interruption. And we can see that within UTC there is actually a 60th second on December 31st at midnight before counting over into the first second of 2017. And so within UTC there are periodically minutes that have 61 seconds. And the difference between UTC and smeared UTC is that smeared UTC uses a 12 or 24 hour depending on the on the reference frame period where the leap second is slowly added into every second. So every second is ever so slightly longer than it would be on a non leap second day. This is how a lot of computer systems handle the addition of leap seconds. So that instead of having to account for the fact that days have different number of seconds, they just slightly fudge how long a second is over a 12 or 24 hour period. I will leave this last slide here as an exercise. We'll have this updated just so we have some time to look at questions in a little more detail. But I'll talk a little bit about. Date formats are different ways that dates can be represented. There are different standards and these standards both reflect timekeeping systems. So what we refer to as an ISO date time is an ISO 8601 standard for how time should be noted. We get hyphenated elements that are in a strict order. There's a T separator between the time and the date. There are also variations where ISO has a week date specification. So instead of months and days of the month, we have a number of weeks in a year and the day within the week. There's also an ordinal date which is just a year and the day number of that given year. We also have a section on locales because the way we represent and write time varies depending on where you are. Again, I can jump back to this if there aren't, but I see a couple of questions that have collected here that I'll take a look at. And there's also some additional resources at the end of the notebook here. Let's see. So jump back. How are atomic clock standards handled? Is there a calendar system used for the Earth's rotation of year of time? So yeah, so generally I will jump back to this time system. So these are the primary set of time systems that are used. UTC is generally what civil time is aligned to. It is designed to keep within 1 second of solar observations relative to the Earth's. Rotation, UT1 is exactly aligned with the Earth's rotation. But it takes a fair bit of observation. And so UT1 time is actually, typically takes a little bit of time to actually compute. And it's not used for civil time. These other forms are all used for various degrees of observation for time as relative to different celestial bodies. So ET or ephemeris time, also called TDB or teradynamic time, is looking at a day reference. Basically they're different references to astronomical bodies and the way we keep time and account for relativity. Because your time system is also going to vary when you leave the Earth's orbit because gravity, gravity affects time. When you're near a larger mass, time is going to flow differently. And so most of the time, if you're familiar with these other time systems, you're dealing with something that has to do with astronomy or very specific aspects of dealing with relativity. But for our general human day to day observations, we think about utc. Often UTC and GMT are used interchangeably. Technically, Greenwich Mean Time is different than universal coordinate time, but they're pretty commonly interchangeable in terms of colloquial usage. Yes. Someone hopes we get a way of daylight saving time entirely. The European Union still plans on doing that. The United States still has a proposal to do that. There are complications with all timekeeping systems. You know, China has its own problems with a. The one time zone policy being over a large geographic area. The higher you the, the farther north or south you are on the globe, the more things like daylight saving time tend to to impact your alignment with solar noon some. You know, I live up in Minnesota right now, so there's a fairly significant difference between daylight time and standard time. If you live in the southern United States, there's not a lot of variation over when solar noon actually aligns relative to your time zone. Let's see. There's a question about how do you avoid granularity issues when using the select function on date objects? I. I suppose it depends on the sort of input you're looking at, but I'm guessing if you're looking at the full form of date objects, the granularity may be different than what you're expecting. We have a date value function which is used as an extractor that can be used to extract multiple elements. So say I have a list of now and today. If I were to say I want to pick out select from yesterday, today, now and tomorrow, and I want a date object that looks like this, I am only going to. This is select. We were to look at something structural like cases we would pick out today but not now because we're looking at the the full form of something like this. If we were to do a different operation with select, we could say I want a something where the date value for the elements of day is 8. Then it would pick out both of these elements. We also have a date select function which I can show here that lets you create give spec custom criteria for selection of dates regardless of granularity. So if I want any date that has a month that is in May, this will pick it out regardless of granularity. I can do selection from week number. There's a large number of examples here in this section, so I won't get too deep in the weeds with this one specific question. But I would say look at date select, look at date value. If you still have questions, feel free to contact us and we can get into the specifics a little more. In regards to date and time series, how can I show the time zone will be honored and not converted? Dollar time zone pipelines falling through nonlinear model fit anything. Yeah, so the. The standard representation of dates traditionally in the Wolfram language has been up through before version 9 or 10, I believe was a date list, which is basically a list of year, month, day, hour, minute, second. This has an implicit time zone that is dollar timezone. And there are complications with how those interact because we're carrying around data here that's undecorated. If we look at our canonical date representation in date object, look at the input form and see that the object itself is carrying around the full qualification of this is the 6 element date. It's an instant in time. It's on the Gregorian calendar and this is the time zone associated with it. So I have all the information I need to convert it to a different time or a different calendar. A different time system. The time system is elided here because it's using the standard form, but it could be included if it was using something other than our standard time system. I don't know about the specific case with time series that's being alluded to there. It might be easier if we have an example to look at. Maybe it's something that you could contact our support wolfram.com email address is our technical support address and they can handle any specific questions or direct them to me if we need more details. Is there a function to return the last date of a given month? There is. We can say so. There's a number of different ways to do this, but if I were to Say something like I want the. I want the. This is not the most convenient form to look at that, but there is a end of month day type. So the difference between the date functions in Wolfram language and the day functions is that the date functions are general purpose for doing data arithmetic. Day functions are specifically focused on the variation that different types of days will encounter. So if I were to say. If I say next date of end of month, I will get that same date which is the end of this current month. I can also give any reference point I want. So I could say I want the next date from. The 4th day of August, I want the end of month. I'll get the last day of August. In the next Wolfram language version there will also be a duration function. The duration function that currently works on audio objects will also work on dates and can tell you how long a given date is, if it's a month, etc. Yeah, this end of month day type is associated with the day functions and will give you. You can ask for something like I want the. I want to know what two Thursdays from now is. It will give me the date not + n number of days, but the next. The second to next instance of a Thursday from right now. Level space. Yeah, so there isn't a. A given function that is necessarily I want this day two days before the end of the month. End of month is kind of a. A specific criteria here. You could generate something with date select, but it might be a little more. More decorated than you're. You're necessarily looking for. See here. Looks like that's the end of the immediate questions. I see. Okay, the. Like I said, the notebook that I used in the presentation today will be uploaded to the thread later today. I believe I've left some additional resources. In the end, if you're interested in calendars, the history of calendars, the different ways that calendars are put together, I strongly recommend Edward Rheingold Nachem Dershowitz calendrical calculations. This is basically the end all be all of how calendars are constructed. It has. It's a fairly lengthy tome. It's the basis of a lot of the algorithms we've used in Wolfram language for how we actually calculate different calendars. And there's a lot of good information there. Also linked to the ISO standard for date and time, the IANA time zone database. And then a subject I didn't talk on super thoroughly is locales, which IANA also maintains a sub tag directory for differences like how you know they. How Time is noted differently in the United States than it might be in the United Kingdom or in Spain. Even when we're just using numeric elements, the ordering of them varies. And yeah, that's another exercise that if you're interested in, there's additional information here. See, it looks like I'm pretty much at time here, so I will go ahead and stop sharing. If there's any last minute questions that I did not get to our Livestream team will be able to pass those along to me and I can either get back to you directly or you said our support team at Wolfram Research is also very useful and knows how to get a hold of me if we have a more complicated example that they're not able to tackle. There was one last question. Dollar time zone fraction Fractional seconds so the time zone that is reported will currently give a number offset from GMT and hours. Some offsets are less than an hour. The Wolfram language understands a time zone specification that is numeric regardless of whether it's a real value or a integer or a rational value. So you can specify a numeric time zone that doesn't actually get used in anywhere in the world, but you can have a numeric time zone that is, you know, a third of an hour offset from gmt and the date framework understands it. All right, well thanks everyone. I will go ahead and stop here and if there's any follow up questions, feel free to reach out to us. Thank you.
More from Guy

Cheryl Strauss Einhorn | The Human Edge: Smarter Decisions in the Age of AI | Talks at Google

Rachel Glennerster | Innovation and the Center for Global Development | Talks at Google

Rebecca Winthrop | Rethinking the Purpose of Education in the Age of AI | Talks at Google

Dr. Robert Wachter | A Giant Leap: How AI Is Transforming Healthcare... | Talks at Google






