Date Formats and Do Not Disturb

Perhaps fitting that my return to this blog is dealing with the same thing as my last post, date formatters. Hopefully if you are an iOS developer you have searched your code for YYYY, ISO week date year, and replaced it with yyyy. However if you are showing the date to the user then you probably shouldn't be using your own format string anyway.

The details are hazy, but I believe around iPhone OS 3.0, my cousin Matt did some digging into the system. At the time he wanted to build an app that would've required or worked better if it could run once a day via something like the cron. He discovered that either part of Springboard, or at a similar level, was a scheduler much like cron. Of course this was all unavailable to developers publicly, but you could submit jobs, to this scheduler and at the appointed time it would kick off the requested application. As I recall he also noticed that something like a daily alarm would only have one entry in the plist, and when the alarm was woken up to go off, it would put itself in the schedule to go off tomorrow.

Now one might wonder how this affects something like do not disturb which should in theory turn on at a certain time of the day, and turn off at another. Only having one process, this scheduler, running all the time saves battery instead of having the alarm, do not disturb, calendar, etc. all checking to see if it's time to do something. Indeed I believe the scheduler itself isn't running all the time since it knew when it next needed to do something it could also lay dormant until the appointed time. For good or bad this scheduler seems to take a full date and time (and probably time zone information as well), and so if you schedule that do not disturb needs to run between Jan 1 and Jan 6 and you date formatter string has YYYY instead of yyyy, then it is going into the scheduler for 2012-01-02 08:00:00 for example. The reason why it will start working again January 7th is that the ISO week date year will be 2013.

The take away is dates and times are hard. They seem straight forward, but can quickly turn into a mess. You should double check your formatter strings to make sure they mean what you want. You should search your code for YYYY and change it to yyyy if that is what you really want, and you should really consider how you use NSDateFormatter in case you would be better served using styles instead of a custom date format string.

NSDateFormatter

Apple has provided some extremely low hanging fruit when it comes to support different regional settings. I have my phone set to use Swedish regional settings, it just makes life easier to have times, days of the week, and numbers ​all displayed the same way I see them in the world around me. However it does seem to cause a lot of problems when using certain iOS apps. Here is part of a screenshot of my phone today while using Path.

Path 2.5 Screenshot​

You can see that it was 2:16pm when I took the screenshot. You'll notice that the phone displays 24-hour time in the status bar as it's done in Sweden. Then you'll notice the two times coming from Path, 2:16 em. Em stands for eftermiddag (Eng: after midday), had I taken the screenshot a few hours earlier it would have shown fm, förmiddag (Eng: before midday).

Other ways the Swedish region differs from the US one, up until iOS 3 or 4 times were actually displayed with a decimal instead of a colon. I'm not sure on why this changed, but more than one app didn't work right on my phone since it was trying to manage times and math on its own and didn't know how to deal with 14.16. Decimals and commas swap meaning in numbers, in the US you write 1,000,000.00 and in Sweden it is 1.000.000,00 or sometimes 1 000 000,00.​

The fix is simple, supports all regions Apple supports and makes your code less fragile. The code smell is this line:​

[dateFormatter setDateFormat:@"LLL d, yyyy h:m a"];​

If you are calling setDateFormat: and displaying that to the user, you are probably doing it wrong. Instead use the constants Apple provides to make it work, and it will work universally. The above becomes:​

[dateFormatter setDateStyle:NSDateFormatterMediumStyle];

[dateFormatter setTimeStyle:NSDateFormatterShortStyle];

All the information you need can be found in the NSDateFormatter documentation. Also initializing a NSDateFormatter can be expensive, so as appropriate initialize one, use it many times, e.g. displaying a bunch of cells for a table view.

Update:​ Path fixed their date formatting, I believe it was, or around 2.5.5, certainly around the support for the iPhone 5. My thanks to them, though at this point I've created such an aversion to the app that I'm not sure I will overcome.

Rethinking the App Store Hack

Putting my thoughts into words and posting publicly has had its intended effect. I've been rethinking about my idea, and realize that unfortunately the cons outweigh the pros. Putting the same app up in the store would lose all my reviews and history. I believe that at least some of the continued long tail sales success of Lexikon is based on the reviews and history. I could be wrong, some point to most app purchases being impulse based, but Lexikon is a tier 3 app, and that's when people start to do a bit more homework (and thus my support requests from people who obviously didn't read the app description have dropped to zero).​

I haven't really escaped the position of being between a rock and a hard place. Though I think now I'm just going to have to charge head on, make my final update to this version, leave it on sale until development of the 3.0 version is done, and submit that as a new app

I think the game has been disrupted by the App Store and right now developers and the market ​haven't quite settled into what and how sustainable business works.