I ran into an interesting bug with Ingerchat recently.  A friend was visiting his family in Denmark, and reported that Ingerchat wasn’t working for him.

I ran through a number of scenarios. Ingerchat didn’t work from overseas? I got a free VyprVPN account, connected my phone to it, and routed the VPN through an Denmark IP. But that worked.

Maybe using the Denmark region or language caused the problem? I set my phone to both, but again, Ingerchat was fine.

I looked in my server logs and noticed that a call to fetch conversations was failing. That call fetches all conversations with unread material after a specific date and time.  It looked like the date was invalid, but my logs didn’t tell me what was going wrong. I put in more logging, and asked my friend to retry.

The next day (this is nine time zones away), he did, and I got another look at the log. The date being sent was similar to “2016-03-02T14:15:28.010 0100”. That looked correct, but I fired up the Node REPL to check, and discovered that that is not, in fact, a valid date string, due to the space before the time zone. Instead of:

2016-03-02T14:15:28.010 0100

it should be

2016-03-02T14:15:28.010+0100

Oops.

So now I had a cause. Since this date comes from the app and doing a release of an iPhone app takes 4-5 days, I couldn’t fix it on the app. I had to work around it on the server. So I did a hack to replace that space with a “+”.

Problem fixed. For my friend. But now the question: why was the date being sent in an invalid format?

I fired up the debugger on the app, set the time zone to Denmark, and found that the “+” was, in fact, being generated. So why wasn’t it making it to the server?

Turns out than in a URL, a “+” is a special character that is used as a substitute for a space. so “2016-03-02T14:15:28.010+0100” is interpreted by the server as “2016-03-02T14:15:28.010 0100”. I was encoding the URL using

 NSString.stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding

But it turns out that’s not good enough! That call does not escape the “+” symbol. So to fix this I needed to add an additional call to escape the “+”. My URL encoder now looks like this (in what is one of the few bits of Ingerchat still written in Objective-C):

return [[string stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding] stringByReplacingOccurrencesOfString:@"+" withString:@"%2B"];

Problem fixed.