Fail-safe Algorithm for iOS DateFormatter

(CC) by Dean Meyers
Algorithm use example.

iOS applications in most cases use REST API to get and post data, we rely on the data we receive to show feedback UI to the user. In some cases we can continue without a property and give it a default value when we couldn’t parse the data, but in other cases the app can’t deliver it’s purpose without a property or an object expected to be given to us, what do we do then?

I would like to share with you an algorithm I wrote, it’s efficient, fast and simple, to make sure you could parse any date format given to you from a source other then the app.

If you are interested to see the code right away jump to end, if you’re curious to read how and why I wrote it, what are the benefits and what makes it efficient, then stay tuned.


Background story

A year ago I was working on a big project, the server side was developed and managed by a different company, we built the API and started developing the app. The app relied heavily on dates, all from post date to last sync date. We (server side and our team) agreed on a date format that will be used though out the app, we will send dates with this format and receive and parse to that format, and everything worked great.

Until one day during development the app behaved weird, and in rare cases crashed. After a few days and many phone calls we figured that the server for some reason sent us wrong date formats, since the app relied on dates, 89.5% of the app was unusable. Although the source of the problem was fixed in the server side, I had feeling that this kind of thing could happen again. Long story short, the fail safe algorithm was created to deal with this issues in the future.


What are the benefits?

  • Covering most of the known date formats (you can add new ones).
  • Flexible and efficient = Faster phrasing.
  • Easy to read and understand.
More on readability and its importance: https://medium.com/ios-os-x-development/making-your-ios-application-easy-to-read-with-these-simple-steps-b63067900b72

DateFormatter is an expensive object and should be used with care, performance wise it should be shared in your app and not created on demand, every time you want to parse a given date from “String” to “Date” object you need to provide the correct date format otherwise it will fail.

What makes it efficient?

Our DateFormatter object needs a format to parse the date string to, if we previously found a match we will use it all the time hence saving time, if the given date string has a different format and we couldn’t parse it using the current selected format we locate a suitable format and use it. simple, easy and well understood.

Public API for parsing date.

When we find a format suitable for parsing a given date we try and parse all dates using that format, only when we fail we try other formats until we hit the one that fits, once we found it we make it the default format.


Full algorithm :

Feel free to add new date formats if these cases are not covering what you need.

How to use it ?

DateFormatter Extension: