Those poor programmers who get the bug report "Can't schedule things in the early 1800s due to scrambled dates", and have to decide how much time they're willing to spend fixing it.

Here is the mail I sent you a year ago when I read your book: I just started reading your book and I think I found (part of) a solution to your question about the iOS calendar break down you mention on page 285f.. In your book it says that it breaks in the year 1847, so obviously I tried it out myself on my iPhone and to my surprise it already broke in the year 1893 (btw it starts working again if you scroll to the year 200). I have to mention that I am German and reading your book in Germany and not the UK. So I thought maybe it has something to do with the time zone you are in. So in the iOS-settings I changed the time zone to London and sure enough the calendar breaks in 1847. To figure out what is going on I naturally tried a few other time zones and found that in the US it doesn’t break until 1583, same in China, Australia, New Zealand and some other countries. To my surprise the year even changed in the same time zone if you choose a different location. For example in Moscow it breaks in 1916 while in Minsk (same timezone!) it breaks in 1924. In Madrid (same time zone as Berlin) it breaks in 1900 instead of 1893 and in Hong Kong (same time zone as China) it breaks in 1905 instead of 1583. I soon noticed that the earliest year that it breaks is always 1583 which is the year the Gregorian calendar was first introduced. I also found out that 1847 was the year when the „Railway Time“ or Greenwich Mean Time was introduced in the UK and 1893 was the year that the time zones in the German Empire were unified to one common time zone. In the Casey station in Antarctica the calendar breaks in 1969 which is the year the station was built. So it seemed quite obvious that the calendar break down must have something to do with the time zone. I looked up how the time zones are managed by iOS and found that it is based on the tz database (or Olson database) which is a database which keeps track of all changes in the time zones around the globe including daylight saving times and leap seconds. In the database the earliest year for each location is usually the year that the time zone was unified in the respective country (1847 for London and 1893 for Berlin). Before that the „Local Mean Time (LMT)“ is used which is calculated from the longitude of the location. The system also only can deal with the Gregorian calendar which explains why the earliest working year is 1583. What I couldn’t figure out yet is why in some locations it works until 1583 while in others the respective „first year“ of the introduction of the time zone is the year it breaks. I hope you found that helpful and if you find out why it’s 1583 for some countries and not others I would be very interested.

The bad news is my calendar app works perfectly (iOS 14.4.1). The good news is that I have scheduled a haircut for 1pm February 10th 157 BC. I hope I don't miss it.

15:45 "200 ... is a multiple of 400" Well, you are the mathematician, so I'll take your word here.

When the calendar breaks depends on your time zone! On NYC time zone it breaks at year 1583, but if I change my time zone to London it breaks in 1849.

People in 1848: That’s why I use android

One thing the calendar did get right (and I'm still keeping to the old notation), AD 1 was preceded by 1 BC. There was no year 0. This can't have been accidental, it must have been programmed by someone.

7:15 "That will be a Sunday!" I'm thinking that by that point the sun will have already devoured the earth, so maybe every day is a Sunday at that point. Or maybe the sun will have burnt out, in which case there'd be no such thing as a Sunday.

the calendar is having problems adjusting to changes that we have made to the particular time zone. I'm located in Singapore, and the calendar breaks in 1906. a quick check shows that there was a shift in the time zone the year before, so the calendar has trouble calculating a particular date and time that technically doesn't exist for that time zone. the same happened in London when GMT was implemented in 1848 and the time was adjusted.

One small thing. I noticed that the calendars aren't actually missing the month of December, theyre missing January, but the months are labelled Jan - Nov. Almost as if they're reading index 1-12 from an array, instead of 0-11, for the month data.

On my iPhone (software version 13.3.1): Scrolling back in “year view”, I got to 1583 before year headers disappeared. They returned at 299. I noticed, also, that when I switched to “month view” for my scrolling, all years from 1583 to 299 (and backward a few years from that) displayed nicely. When I switched from “month view” back to “year view” at a year before 299, the calendar crashed. I guess it was tired of my shenanigans.

When you get back to year 1, it repeats the year 1 and starts going up, this makes sense since it is now BCE. I think that part is actually working correctly

I'm a time traveler from February 31, 1848 - can confirm December didn't exist.

"That would be a Sunday" Ironic, since the sun would have been long gone by that point

Love your vids Matt, thank you for putting in so much research and time for such rewarding videos, MUCH appreciation bud, keep them coming.

In Denmark this breaks around the year 1895, which is hardly a coincidence: Denmark officially switched from solar time in Copenhagen a Greenwich-based offset time in 1894. I once ran into an issue with this myself: On macOS, the offset prior to the switchover is 0:50.20, and a lot of software doesn’t handle second-based offset.

My years went away at 1583 then came back at 299, when I got to year 1 it started counting back up, the years went away again at year 3800 and the app completely locked up some time after that.

"I can't keep doing this forever" he says, with the clear desire to keep doing it forever hidden in plain sight upon his marvelling face.

I got down to one - then it goes up again, but I noticed that the year one has 24 months instead of 12. I am in the newest verson of iOS 14.

When February had 31 days, January had 28 days.. there was clearly an off-by-one error at the start of this video..

That bug might be handy in the Apple Calendar any% speedrun.

"I can't keep doing this forever" What the hell do you think I'm subscribing for???

In the French version of the Apple calendar, the years start going crazy below 1912. There is no year 1911 as it jumps to 1910 which is the earliest year to even have its number written.

This bug has been around for a long time, I remember practicing mental calendar calculations and having to go on my computer to check out the answer!

The issue with 1583 might have something to do with the transition between the Julian and Gregorian calendars. The Gregorian calendar first went into effect in October 1582, making 1583 the first full year of the Gregorian calendar. October 1582 was actually 10 days shorter than usual because Julian Oct 4th was followed immediately by Gregorian Oct 15th.

"Hopefully I can get it out in the next couple days" Well... It's still the 3rd in this bit of Canada, so I think it counts. Just tried this on an Android phone with my calendar app. I couldn't scroll the same way, I could only go a year at a time, but luckily I've got experience playing bass so I just used that technique to get through it. It wouldn't let me go past 1902, which coincidentally is the same distance from 1970 as 1970 is from 2038. Hmmm.....

"Today's date is Mar 29, 2020" an innocent time, indeed

A software tester walks into a bar. Runs into a bar. Crawls into a bar. Dances into a bar. Flies into a bar. Jumps into a bar. And orders: a beer. 2 beers. 0 beers. 99999999 beers. a lizard in a beer glass. -1 beer. "qwertyuiop" beers. Testing complete. A real customer walks into the bar and asks where the bathroom is. The bar goes up in flames. ... Thus is just the story (obviously not mine) I remembered when watching this video 😆

Fun fact: There is no year 0 in the Gregorian calendar. It flips straight from 1 BC to 1 AD, with 1 BC coinciding with the year 0 in the astronomical calendar.

I never thought that watching a guy scroll through his empty calendar would be so exciting.

mine breaks at 1896

I was expecting, with a name that includes "AbsoluteTime" it would be the number of seconds since the big bang or something (an approximation is fine, time is an illusion anyway. lunchtime doubly so).

Every C-programmer knows that the time started January 1 1970

"200 is a multiple of 400". Come on Matt, you're making the Parker Square jokes too easy.

version 13.7 reporting in, near the end of October 2020. The bug lives! However on my phone it has shifted back substantially... to the year 1583. It comes back again in the year 300, then continues backwards for at least another 2500 years

"and fun fact, that will be a sunday!" just really got me for some reason

16:46 well hey, at least they took into consideration that there was no 0BC

The bug seems not to be related exclusively to the time zone: different cities within the same time zone lead to different results. For example if setting location to Paris, the last year correctly displayed is 1912, but for Rome it is 1895. Other variants I have found: 1918 for Saint Petersburg in Russia, 1917 for Athens, 1919 for Jerusalem.

My crashes approximately slightly before year -4000, after year -3890 - years disappeared again. Thnx for that experience, Matt)

fun fact, as of today (dec, 17, 2022) if you go back to the year -4712 on iPhone calendars, it reverts into just saying January, February, march over and over, again with no year, so while its better, its still not perfect, cheers!

"What happens when we get past zero?" "No." "Noo...." "It's counting back upwards!" *A superb twist fit for the silver screen*

First of all, I've gone forward in my calendar to the 12000s and gave up on anything interesting. Going backwards is far more interesting, as the years just get weirder and weirder, rather than breaking suddenly. While the calendar doesn't actually use negatives for BCE years, I'll be using + and - to differentiate. The years are ordered in reverse chronological order (i.e. as you'd encounter them scrolling up). *Year +1583:* Earliest year with year labels in the current block of time with years. (Consistent with my fellow EDTers in the comments.) The years preceding this one seem to be picking up month spots 1-12 instead of 0-11, as the January-November which show up in those years behave like February-December in a normal year, and the following January is shifted by three days as if there's a hidden month of 31 days we can't see. *Year +300:* Last year before year labels stop. There are two Februaries, which each have 29 days and which each start on a Thursday. In the years preceding this one, the years behave perfectly normally. *Year -3401:* This is the earliest year in which February is labeled properly every year. In the years preceding this one, every fourth year (where there's correctly a February 29) is labeled correctly, and the three intervening years, it's labeled as March instead (so there's two Marches). *Year -3497:* This is the earliest year in which February is labeled at all. Note that this isn't -3496. I think this is because of the fact that there's no year 0 on the calendar throws off the "every year divisible by four" calculation, since it's seemingly programmed as "every fourth year" instead. *Year -3701:* This year has unique behavior. The year begins on a Monday. The first March begins on a Thursday and has 29 days. The second March _also_ starts on a Thursday (though it should be a Friday by calendar logic) and _also_ has 29 days. April starts on a Sunday instead of a Friday, and the date sequences are normal from there on out. *Year -3702:* The year which _should_ display as -3702 is not labeled with a year, and it only has nine months (May, May, July, July, August, October, October, December, and December). The year which _should_ display as -3703 has only seven months (May, May, July, July, August, October, and December). This seven-month behavior is the function which it takes going any further back. Here's the interesting bit though: if at any point earlier than -3701 you start scrolling forward again, the years will be labeled correctly, but they'll have thirteen months (January, March, March, May, May, July, July, July, August, October, October, December, December). Once you return to -3701 it'll go back to fairly rational calendar behavior. You can get some weird situations where years get smashed together depending on where you start scrolling forward and backward. My record is nineteen months: May, May, July, July, August, October, October, December, December, May, May, May, July, July, August, October, October, December, December. And the internal date continuum in these wonky years is actually consistent! *Year -3801:* This year follows the above rules for earlier than -3702, but it will never itself be labeled with a year. *Year -3802:* From this year and earlier, no year labels are ever shown, and all years are ten months: April, May, June, July, August, September, October, November, December, January. Dates are continuous, but it skips three days in the week between years (i.e. if one January ends on a Monday, the following day, April 1, is a Friday). *In month view:* No matter which year you zoom in on in these early glitchy years (before -3497), the months will be continuous as they should be, and labeled properly. If you try going back to year mode, the calendar crashes. *If you try to rotate the screen:* No matter which year this occurs on (before -3702), the phone is just as confused as I am about how this works and just straight-up crashes the app (I think it's struggling to force the glitchy calendar onto the screen). No, I'm not going to test this out on every time zone on the planet. This was far too tedious as it was.

I remember doing this years ago, it also managed to make my alarm snooze for negative time back in iOS 8. The negative years also would just count up and I'd always compare the current date to itself in the negative year lol

OMG!!! This is the worst cliffhanger in the history. It's even worse than Breaking Bad's "To’hajiilee"!! What happens when you reach that three digits number again??!! (I don't want to spoil it to those who have not seen the end yet) I'll have to buy an iPhone to get it solved... I was thinking of getting a copy of Humble Pi but now I have to save it for that iPhone. Once I get it and see what happens on THAT NUMBER, I'll sell it and get a copy of your book. You look like such a cool guy, Matt! Thanks a lot for all the content you made over the years...

4:20 marks the historic year of 1848 where January was banned and April was loved so much they made it a second time

Going from year 1 to year 1 and back up again makes sense, since that’s how the calendar is supposed to switch from BC to AD. It looks like they dropped the BC.

Everybody: Jokes about Apple Technicians and messing with time. Me: I didn’t know that people kept the same iOS version that long. (iPhone 8 with iOS 11 in 2020?!?)

i got the bug on 1894 also going inside of the months is very weird... there’s some days on the top row and then on the last column in the other rows and the rest of the days are blank. pressing them moves into a different day then i clicked on. okay

Apple engineer 1: Should we make sure our calendars works for nineteenth century and before? Apple engineer 2: Nah. No one will ever notice it.

The years that were broken didn't have 12 months. As far as I could tell, most of the time there was no december. Other years had showed only 9 months with July, August and December missing. As a software developer my professional opinion is: It's messed up.

Hi Matt! The earliest year I can reach on my iPhone in French is 1916 (1915 being the one working or not depending of the scrolling direction). Even worst :) After is the same as you in 199/200 and as mentioned in other comments, going from 1AC to 1BC seems correct in my opinion.

so I scrolled all the way back on the calendar(on iOS 14.4) and I got to 4712 BC!!! and then it starts repeating January, February and March like a loop so you are basically still in that year, I was surprised

So the years start coming and they *do* stop coming

in USA, my iPhone 8, software version 13.3.1 : Breaks scrolling back in calendar at 1582 (1583 appears normal). It then starts showing year numbers again at year 299 (has year 296 as a leap year). At year 1 it then starts again with a 1 and counts upward if continuing to scroll back and continued counting upwards further than "2000 years before year 1" for sure when I got bored of that and quit. (scrolling forward it shows years definitely further ahead than year 5000 when I got bored and quit)

apple iphone + gmail + google Calendar + google maps. That's been the far better combination than going with apple apps for years now. I guess here we see why google focuses on engineers while apple focuses on designers.

It is no coincidence that 3.14 am is the time the UNIX clock runs out. Pi pops up everywhere.

10:29, classic Parker explanation. It’s like you’re trying to keep the Parker Square alive.

"Let's go back to zero" you are not without knowing that year zero doesn't exist. It seems the calendar tries hard to agree with the Gregorian calendar when and where it was first adopted, and then of course fails at that. The fact that scrolling in the other direction changes the result makes it even worse, it shows that the code for it is stateful...

The years in BCE work all the way up to 3818. After 3818, there is 2 or 3 of each month per year. It doesn’t take much more scrolling past that to make the whole app crash

thank you for allowing me to discover that my apple calendar can scroll back to the years i’m writing about in my ancient history dissertation! (sixth century bce). and even further to the years i covered in my pre-history module! also if you get lost in the years with no number if you click on a month it tells you in the top left corner what year you’re in but the calendar dates are very broken lol

The most likely reason: the Gregorian calendar was introduced in 1582 (in many countries anyway). If you extend it backwards as if that calendar had existed before then it is called the "proleptic Gregorian calendar".

15:40 "The year 200 is a multiple of 400." You sure about that?

Today was a Sunday in the year 1CE and a Friday in 1BCE. What I find interesting is that 1BCE is a leap year, so leap years occur during odd years in BCE if we apply our current calendar to the past

I continued scrolling. After the year 3839 BC, the calendars break again. There’s 8 months now and they’re May, May, July, July, August, October and December. This also changes the further back you go. I also scrolled forward past 11,000 AD and it’s still normal there.

When it got to year 1 and started counting up again it reminded me of that moment in The Dinosaurs when someone (the spunky teenager I think?) asks "Dad, why are our years counting backwards?".

I was trying this on my iPad and now every time I try to open the Calendar app it crashes, even after a reboot. Oops.

As a programmer, my guess is that it needs to calculate at a particular part of table whether it needs to render a header (the year) or a row of 3 months. The code that calculates this category based on the table's position is buggy and that why it renders incorrectly.

Just tried it on my iPhone 11 pro (this is as of the 16th april), and it brakes at 1583 aswell... someone in the comments mentioned time zones, I’m from Slovenia if that helps... EDIT: I went to the extreme aswell, and found out the years come back at the year 299/300 for me, depending on which direction you come from, not at 199/200 and the months are all correct aswell, also at some point towards the year 300, December just disappears and comes back EDIT AGAIN: (why am I still doing this) if you get down to year 1, it turns back around (3, 2, 1, 1, 2, 3...) EDIT FOR THE LAST TIME: Well, I continued in the “negative” direction and all the years are there, I came back to 2020 (well, negative 2020 actually) and everything all the way there was, well, there... EDIT: ok, this is seriously the last edit, I’m closing the app now... but the years disappear again at “negative” 3800

1583 as well. Also 300 AD does the weird “I can see you scrolling forward in time but not backwards”

Have you tried tapping on a date once you hit that bug... The month view is totally screwed up too. Just looking at days of the week, it's got the first day of Jan right (Saturday) but the full month of Jan is actually under February. This is a view recycling bug of some form. If you are ever so careful when you scroll backwards and have 1848 (the date label) go off the screen, you can get it so you go just far back enough that when you go forward you get November TWICE. Typically this sort of view is a single column, like a list. But this is a double column. So my guess is that you hit a year end and there's some magic combination of values which causes it to recycle the view incorrectly. So you end up with October 1847, Followed by 2 Novembers, then a missing month, then February 1848 correctly displayed. IF you scroll back (and then forward) just enough. Go back so the date label is no longer showing but the labels for October and November are still showing and the first row of dates. December 1847 will be missing anyway! If you scroll far past that point, then when you come forward you will get one November and BOTH December and January are missing. If you keep going back you see December is always missing, but actually so is January. The month underneath the label for January is actually February's dates (and they are correct!) So 1848 isn't the year it goes wrong, it's a year a little before that; depending entirely on how far back the view is being calculated off screen so its can scroll into view. That's why if screws up differently when you scroll slowly versus quickly. Now, if you go back to the year 199, which is the last year which appears correct, and then scroll into the year 200, you see several other strange things... 1. It's captured as a leap year which by Gregorian Calendar standards it is not, although the Julian calendar was in effect back then and under that calendar it WAS a leap year. 2. There are TWO Februaries. 3. There are TWO Marches. 4. December is missing (for the first time.) 5. There are THIRTEEN months in the year 200, even with December missing. When you get back 1,801 years, in microseconds, from Jan 1 2001 you've exceeded a 51 bit binary number several times over so there's no way it's using CFAbsoluteTime to do this. It's got some form of other logic it's using to figure it out. The other reason is that if that was the problem then Calendar on the Mac would almost certainly be broken 2. And it's not. :) Somewhere in the middle of all that is the great Gregorian calendar kerfuffle, which is of course where leap year maths properly started. And..... October is NOT missing the 10 days between the 4th and the 15th. The switchover is entirely missed. In the grand scheme of things that makes no odds but it's just another example of sloppy (if you count not catering for people who want to add calendar events centuries in the past as sloppy) programming. :) I've checked to see if the difference between the year 200 and the year 1849 is any special amount of microseconds and it's not as far as I can tell. So all in all, this is almost certainly not a maths bug. It's a good old fashioned coding bug... But thanks. You helped fill the early hours for me (now that time is almost meaningless anyway; ironic!) :)

Just a minor correction, 64 bit floating point is 1 sign, bit, 10 exponent bits and 53 mantissa bits. The mantissa is an unsigned integer. Also, most applications on macOS are written using Cocoa or Core libraries, of which the common library is called Core Foundation abbreviated which is why a lot of the C API uses a CF prefix, or just the Foundation library in Objective-C (Cocoa). I'd agree with your programmer friend that it is quite likely the API that was used in the application. Floating point would also break due to both rounding error since we're beyond the available precision, which might help to explain why it breaks in such a strange way.

Crazy! With my iPhone SE, Version 14.4.2 I got to Year 2 without problems. It didn't display the 'first' Year 1, it just had the months back to back. The 'second' year 1 displayed fine, and it counted the other way after that. I noticed the leap years were of by one year (since the calendar didn't have year 0) so 2021 was a leap year (?). 4712 (B.C?) was the last year. The next year (4713) was a normal leap year (with no label) and after that it just displays the starting three months from the previous year, over and over again (January starting on a Monday, February starting on a Thursday and going to 29, and March starting on Friday). I can scroll upwards for ages, and as soon as I scroll down it is back to 4712. I hope this helps, sorry for rambling on.

Crashing at 1583 makes perfect sense, the gregorian calander first started rolling out in 1582 Maybe these problems are nothing to do with maths and binary errors but more a programming error for changes to calanders

I was able to scroll back past year 1 where the years started to count up again. At around 3700 the year display vanished again. I was able to scroll back a while more until the screen just locked up. I also noticed that while the years are not displaying, if you select a given day on a one of the months showing it will show the year in the while in the month mode. Thanks Matt, something to do while we can't go outside.

very interesting! the calendar on my iPad breaks in 1892 (first broken year). Also, unless I can't read, August has 31 days and not 30 (like in the broken years), and that throws of September (30 actually, not 31), October and November (respectively)

Mine matches the years missing between 300 and 1583. Interesting note is that if you click on a date in one of the funky years, the missing dates are actually there when you go through weeks or days. (iOS 12.4.8) EDIT: OK so a bit of a funky thing. I went into February 1581 (one of the missing years and 31 days in February) and tapped on each day. The heading says “February 1581” when you tap on each day UNTIL you tap on the 11th where the heading switches to “March 1581”. I have screen captures if anyone is interested, but I suspect it’s repeatable for any of the missing months for whatever years applicable to the iOS running. EDIT2: This weirdness occurs in every month UNTIL November 1582, where it rights itself. Interesting note is that 1582 has different months missing in the year view when you scroll down to it versus scrolling up to it. There are only 8 months in the year from one direction while there are 11 months in the year from the other direction. 😹

I tested on my 6th generation iPad. * The year bug starts in 1896 * Years reappear when Scrolling to year 200 * if I scroll all the way to negative years everything looks fine for a long while. * I can make the calendar app crash if I’m in negative years and I switch from year calendar to days and switch back to years

The broken years also have January with 28 days... almost looks like everything is shifted backwards a month, thus the missing December.

As a programmer i am preplexed by this, im not even touching time zones.

The audiobook is inaudible?! How does that work? OH! It's on Audible. I seriously misheard what you said at first. Lol

“9 alot” is my favourite number now.

Teacher: What do you want to be when you grow up? Me: A Matt Parker. Teacher: Who is that? Me: A kid, just bigger. I really love your enthusiasm, on this channel and Numberphile. (Still think the Parker square is close enough)

2021-02-11, iOS 14.4: breaks at 4612 BCE, but there’s a blip at “zero” where year 1 CE and year 1 BCE share a heading of “1”, but it is a 24 month “year”. Currently up to 5500 CE and haven’t reached the upper limit yet. [got too sore and too hungry to go further than 20200 CE - haven’t reached the upper limit yet]

Pi O'clock! Laughed so hard!

This is likely a recycler list view. These kinds of things happen all the time when trying to re-use components to save memory.

When you went down to year 1 AD and kept going, the increasing year numbers were BC, starting with 1 BC.

I checked this in February of 2021 and I start to see issues when I go back further than the year 4712 BC.

The reason I missed my appointment that year.

7:17 Imagine the surprise of all the robot descendents of mankind, in 292 billion years from now, coming to a grinding halt all over the universe due to this simple error of their forebeareres...

It is so buggy that we can't even reproduce the bug exactly. If I try it, the years stop showing at a different number altogether

Matt, at 0:22 you can see the first characters of the parts you blurred out. You can also use the frame advance buttons to see the whole thing.

The 52 bit thing is only the limit of where it can accurately track microseconds. It can still track seconds/days accurately for a while after that by utilising the exponent. 1849 proabably comes up because 10 years is approximately the amount of extra time you have to go before it starts screwing up at that granularity. You effectively get almost another bit of precision because of that.

I never stopped to think about just how far back my calendar goes. Now I want to set a reminder to steer clear of the Theatre of Pompey on 15 March 44 BC.

Just as a general question, why do book covers sometimes differ so dramatically from country to country?

Casually mentions that February gets 31 days while January only gets 28 days.

Thanks for this fun video, Matt! Your brief excursion into Unix time and 32-bit vs. 64-bit numbers here reminded me - Wikipedia's entry on "Unix time" previously had a paragraph that read: --- At 15:30:08 UTC on Sunday, 4 December 292,277,026,596 64-bit versions of the Unix time stamp would cease to work, as it will overflow the largest value that can be held in a signed 64-bit number. This is not anticipated to pose a problem, as this is considerably longer than the time it would take the Sun to theoretically expand to a red giant and swallow the Earth. --- source: en.wikipedia.org/w/index.php?title=Unix_time&oldid=684257821 I don't have the words to explain why, but it's precisely the sort of dry humor that keeps me going.

1583 is the first year (entirely) in the Gregorian calendar. I noticed that the year before 1583 lacks October, which was the month the calendar was changed

Fun fact: Gaussian blur is a reversible operation.

OK, I have an Ipad with iOs 13.3.1, and it breaks at 1905. The months before 1906 are messed up, and 1905 is skipped entirely, and it goes to 1904. Then I switched to settings to see my version, and when I switched back to calendar, it crashed. I was then unable to run the calendar application, because it just crashed on starting. I rebooted and now I am completely unable to start the calendar. Thanks, Matt! You killeed my calendar! LOL!!! Good thing I only use an apple device for games and entertainment...

Some people have a lot of time on their hands. CALENDAR JOKE!!!