A couple of people have asked me about my earlier post regarding the bug in Apple’s date software, which causes dates chosen with the date picker before the year 1582 to come out wrong.

Before I discuss it, you can see the bug for yourself (I’ve only tested this on versions 3.0 and 3.1 of the iPhone OS). Go to Contacts and pick anyone in your list. Choose Edit, scroll down and select add field, then scroll down again and choose Birthday. You’ll see a date picker, and your chosen date in a little box above it. Give your fingertip a workout and scroll the years back, back, back, to 1583. You can see in the screenshot below that I took these pictures on September 22 (that’s why September 22 is in blue). I left the month and day alone and scrolled back to the year 1583. The window above the picker reads “September 22, 1583″. All seems well.

Almost. Look at the year wheel. Uh… where did 1582 go?

And now starts the fun.

Go back one step on the year wheel. We’re now lost in time. The screenshot below tells the story:

I’ve dialed September 22, 1581. The window reads September 12, 1582. Wrong day, wrong year! We’re one year and 10 days off. Is this just a one-time error? Let’s try another year:

Now September 22, 1333 has become September 14, 1334. Now we’re one year and 8 days off! Just for fun, here are two other random days I dialed up, both near the start of a month. Each one turns into a day near the end of the previous month, but a year later. There’s also the Ides of March in what looks like the year 300.

Note that these dates aren’t just a year off, and they’re not just a year and a fixed number of days off. The number of days between the date you dial and the date that gets reported changes as you go farther back in time. In 800 we’re a year and 4 days off, and in 1300 we’re a year and 8 days off. In the year 300 we’re only one day and a year off, but … hey, wait a second. The year 300 is listed twice! What the heck?

There are three pieces interacting here. The first piece is the interface gadget with the wheels. This is a UIDatePicker, which is a standard device in the Interface Builder. To find out what date the user has selected, you read an NSDate back from the picker. This is our second piece. Finally, you typically want to convert the NSDate into a Gregorian calendar date, and for that you use the calendar associated with the picker, which is of type NSCalendar. That’s our third piece. So the user dials the UIDatePicker, we get back an NSDate, and convert it to Gregorian with NSCalendar. And it’s wrong: the result does not match what the user dialed.

These three objects, which should be the closest of friends, obviously do not play together nicely for dates prior to 1582.

I tried a few experiments to figure out where the problem is coming from (I wrote about them briefly in my previous post on this subject), but it’s not hard to guess why 1582 is where things start to go wrong. The calendar we use today is called the Gregorian calendar, named for Pope Gregory XIII who introduced it in 1582 (a good summary can be found on Wikipedia). So any dates prior to 1584 are in some sense pretend dates - nobody alive at that time was using this calendar. But it’s straightforward to run the calendar backwards, inserting leap years where they would have gone, had the calendar been in use. Dates before 1582 are referred to as dates from the proleptic Gregorian calendar. You can create a proleptic version of any calendar by running it backwards prior to its first use.

The calendar in use prior to 1582 was the Julian calendar, and it was this close to the Gregorian calendar. The difference between the two was a tiny tweak to the leap-year rule. When the Gregorian calendar was introduced, they wanted to get the new calendar to synchronize with where the older, Julian calendar would have been if it had been using the same leap-year rule. The difference was 10 days. So they just dropped 10 days out of the middle of October, and Thursday, October 4 1582 (the last day the Julian calendar was in power) was followed by Friday, October 15 1582 (the first day the Gregorian calendar was in power). Of course, not everyone was using the Julian calendar at the time, and not everyone switched to the Gregorian calendar on that date, but that’s when the changeover officially took place.

So 1582 was a weird year for calendars.

And 1582 is the year that’s missing. And dates prior to that are broken.

What to do? I tried a few other calendar algorithms that I found on the web, including several for the Julian Date Calendar, or JDC (not the same as the Julian calendar, unfortunately, but an unlucky or just poor choice of names many centuries ago). But many of the algorithms on the web are buggy. When I implemented them and ran an exhaustive day-by-day round-trip check (taking a Gregorian date, turning it into JDC, then back to Gregorian - and not by using Apple’s software, of course!) I found that each of the code fragments I found on the web had occasional errors, often around the time of February 29 on leap years.

Since I didn’t want to trust a random algorithm on the web, and I knew Apple’s calendar system was broken, I wrote my own. I replaced the UIDatePicker with my own custom picker object, and I wrote an algorithm to convert to and from a format I called Andrew’s Date Calendar, or ADC. Modeled after the Julian Date Calendar, this is simply an integer that tells how many days have gone by since Jan 1, 4000 BC. I ran this through my round-trip checker and confirmed it’s rock-solid from 4000 BC to at least AD 3000. The code can quickly convert an ADC to Gregorian, or vice-versa. And of course it can also quickly convert ADC into Mayan Long Count for my application, and vice-versa.

When I finished my application I went to the iTunes store and bought a few of the other Mayan calendar applications. To my surprise, every one I tried clearly uses Apple’s calendar, because they all work fine after 1584, but are wrong before then. It’s just crazy - either those developers didn’t test their programs, or they tested but didn’t care to fix the problem, but people are selling historical calendars that give wrong answers for historical dates! I’m sure most people use these programs for contemporary events, but still, I think a historical calendar should be accurate and reliable when used for historical dates. I’m glad to say that Maya Date is both accurate and reliable.

In the screenshot below, the leftmost picture shows my little test project. There’s a tab bar at the bottom with just two tabs (”First” and “Second” - this is in fact just the default setup that Apple makes for you when you start a “tab bar project”). The window has two buttons - the top one causes an action sheet to appear. The middle screenshot shows the result.

To me, this looks pretty fine. There’s just one problem: half of the Cancel button doesn’t work. If you happen to tap on the upper two buttons, or the top half of the Cancel button, they work as expected. But if you tap on the bottom half of the Cancel button, your tap is ignored. Forgotten. Nothing happens.

I finally figured out the heart of the problem: the Cancel button is straddling the tab bar. The lower half of the button overlaps the tab bar, and that’s the part that’s not responding to taps. But that just didn’t make sense to me. Clearly the purpose of an action sheet is to sit in front of all open windows (as this one does) and accept the user’s input. I was guessing that my touches were going to the tab bar, but why? The action sheet clearly sits in front of everything.

And that’s how looking at the picture led to the wrong conclusion. The picture shows the action sheet in front of the tab bar, fully visible. But that’s not what’s happening internally. The action sheet is brought up by the UIViewController that is responsible for the big white rectangular region on the leftmost screenshot (everything below the status bar and above the tab bar). When the action sheet gets created, you have to call a method called showInView to tell it which view to be drawn in. Naturally enough, I gave it the view controlled by that view controller. Remember, that view starts below the status bar and stops at the top of the tab bar. So of course the action sheet wasn’t getting my touches; they’re outside of the view it belongs to.

But it seems to me that my mistake was reasonable. If the action sheet really does belong to that view, then all we should see of it is the part that is within that view. The Photoshopped screenshot on the far right shows what I assert should have been displayed. Then the problem would be obvious. But for some reason, they draw the whole thing, even the part that’s outside of the view it belongs to, which seems to violate the spirit both of what views are all about and what action sheets are about. And it’s inconsistent: the graphics extend beyond the view, but the input handling does not. It seems to me that if the action sheet appears in front of everything else (which is what you want it to do), then it should accept input from anywhere inside its boundaries.

The workaround, once we know the problem, is easy: instead of creating the action sheet in the view controller’s view (the white rectangle), we create it in the tab bar controller’s view, which extends from the bottom of the status bar to the bottom of the screen. It takes a little monkey business to get the right variable into the view controller so it’s available when we create the action sheet, but that’s just programming. Unfortunately, it can be a hassle. The iPhone is deliberately designed to let you “drill down” many levels of a view hierarchy - they even have specific view controllers designed to support that. If any of those views will need to put up an action sheet, they’ll all have to somehow get access to the root controller’s view. Ick.

It took me about an hour to work all of this out. In retrospect, both the problem and the solution are easy, but what I saw on the screen kept telling me one story, while the code was telling me another. When I stopped believing the picture and focused just on the program, I saw the problem pretty quickly. Which brings me to the third point: there is so much random detail to master with today’s rich programming environments. Back in the days of BASIC, you learned the language and it got interpreted and that was that. There really weren’t any subtleties. Today things are so sophisticated and complex that they save us enormous amounts of time and effort when they work properly, but they can drive us crazy when things go even a little bit askew.

My first application uses the built-in UIDatePicker object (that’s the slot machine with wheels for picking a date).  I want my app to handle historical times, so I scrolled the wheel for the year back a couple of centuries, and noticed some very strange behavior.  When you ask the date picker for the selected date, you get back an NSDate object.  If you print that out, then you’ll find that the date you get back sometimes does NOT match the date on the wheels.  This is of course a disaster for any application.  Try it yourself: spin the wheels around to May 15, 1152, and check the NSDate returned by the picker object: you’ll get May 8, 1153.  One year and 7 days wrong.

And unfortunately, as you move around you’ll find the days continue to shift: May 15 in the year 852 reports as May 11, 853.  Now one year and 4 days wrong.  It’s a problem, but we can fix it. 

Why is this happening?  I think it’s a combination of politics and programming.  The Gregorian calendar (which we use) has gone through a lot of changes since it was adopted.  Many of these were to compensate for the fact that the Earth takes a fraction of a day more than 365 days to get all the way around the sun.  Back in the 16th century, the calendar had fallen so far out of sync with the Earth’s orbit that 10 days were simply dropped out of the middle of October, 1582.  And before that, people added extra days here and there.

The Date Picker returns the selected date as an NSDate object, which I had expected would take these well-known historical events into consideration.  I figured if I spun the wheels back to October 1582 I’d find a few missing dates.  Instead, the whole year of 1582 is missing!  The year wheel simply jumps from 1583 to 1581.  And that’s where the trouble begins.  The dates that are reported by the date picker start to slosh around at that point, moving further out of phase the first year of roughly every century going back (though not consistently - there’s no slippage in the 4th, 5th, 6th, 7th, or 11th centuries, for example).  Essentially, the date that shows on the wheels does not match the date that the picker says is showing on the wheels.

If you keep scrolling back, you’ll find eventually that the year 300 repeats twice!  The wheel goes from 302 to 301 to 300 to 300 to 299 and so on.

The bottom line is that for anything prior to 1582, the odds are that the day the user dials and the day that the DatePicker reports will be different by more than a year.  Trying to fix this in code would be a real mess.  Happily, before I tackled that I tried running the picker’s date through the NSCalendar attached to the picker.  The result is that the days always agree, but the year is still off by one.  But still, that’s much better!

To work with the date that the user scrolls in, you need only adjust the year by subtracting one if the year is anything from 301 to 1582.  There are two downsides.  The first is that the user simply cannot enter a date in 1582.  But that’s not our fault: it doesn’t exist on the picker!  The second is that the user might be confused by the two occurrences of the year 300 (the NSCalendar year reports the first 300 as 301, and the second as 300).

year shown on the wheel: 1584 1583 1581 1580 1579 … 0302 0301 0300 0300 0209 0208
year reported by NSDate: 1584 1583 1582 1581 1580 … 0303 0302 0301 0300 0209 0208

The whole situation is very strange.  It’s almost as if rather than creating the values on the year wheel algorithmically, someone typed them in by hand, and accidentally skipped 1582 and then accidentally doubled 300.  In any case, if you want to use the date picker for historical dates, don’t use the NSDate object it returns.  Pass it through the picker’s own calendar, and manually fix the year if it’s in the problem range.  Here’s a snippet:

NSDate *date = [datePicker date];          // don't use this date directly!
NSCalendar *cal = [datePicker calendar];
unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit |  NSDayCalendarUnit;
NSDateComponents *comps = [cal components:unitFlags fromDate:date];
int day = [comps day];
int month = [comps month];
int year = [comps year];
if ((year >= 301) && (year <= 1582)) year -= 1;  // correct for UIDatePicker bug
// now work with (day, month, year) and it will match the value on the wheels

One sad thing is that if you convert these components back into an NSDate (using dateFromComponents), it goes wrong again. For example, dial in August 10, 1390. The picker will tell you you’ve chosen August 2, 1391. Convert it to components and subtract a year, and you have the right date. Now hand those components back to NSDate (with the corrected year!) and you get back August 2 again, but in 1390. The year is now right, but that’s still not the date that’s on the wheels.

I know that calendars are complex and wonky things with tons of weirdness, and in some ways it doesn’t really make sense to talk about these ancient dates in Gregorian terms, but I wish that the Apple objects were consistent.  I wish the date reported by the picker matched the date that shows on the wheels, and if not, that the date decoded by the calendar did.  As it stands, *nothing* matches the user interface between 300 and 1582.

If the NSCalendar object is the the thing that understands how the Gregorian calendar works, then I wish that NSDate didn’t have a built-in display that disagrees with the calendar.  As they say, the man with one watch knows what time it is, but the man with two is never sure. Having to constantly juggle between dates and components and calendars and such is not just a hassle, but an invitation to messing something up.

Here’s the experiment. Suppose I make a pair of entangled photons in the lab (that’s pretty easy to do). Let’s call the photons A and B. I’ll keep A in a bottle (speaking abstractly, of course) and I’ll send B into a black hole, where it disappears behind the event horizon. Are the particles still entangled? When B disappears behind the event horizon, is any information lost or destroyed? Is there a net change in the information in the universe? If I now measure some entangled property of photon A (polarization, for instance), will B take on the complementary state, even though it’s behind an event horizon? Pushing the question, suppose a friend travels into the black hole first (abstractly speaking, again) and measures the polarization of photon B when it arrives. Would A, back out here in my lab, then take on the complementary state? If so, would that mean information was flowing out of the event horizon and into my lab?

I’m a writer, Jim, not a physicist. I do know that we can’t use entanglement all by itself to communicate, which implies it doesn’t contain information, but we can use entanglement for real-world procedures like quantum cryptography. So I wonder if the entangled particles remain entangled even when their communications channel is removed.

GTA IV take place in a city that is dense and “realistic”: every street is different, every building has its own texture. The result is that landmarks don’t stand out nearly as well as they did in previous GTA installments, simply because there’s so much stuff out there competing for your attention. The result is that automotive navigation is harder (and you spend a lot of time driving!).

The game also requires you to maintain in-game “friendships” between your character and other in-game characters. The friendships pay off in terms of gameplay, but the game tries to be “realistic” by tracking how much time you spend together doing activities each friend likes: shooting pool, getting drunk, etc. Doing these activities requires a lot of time (my time, that is) and lots of driving, but I don’t get much pleasure from the mini-games they chose to implement (even the ones I originally liked were boring the 20th time!).

In both of these instances, making the game more “real” has made it less fun. In this context, more is less.