JJLISO8601DateFormatter is a thread-safe, feature complete, drop-in replacement for NSISO8601DateFormatter that is 10x or more faster for both conversion to and from dates.
Compared to NSISO8601DateFormatter:
- Date to string: 12x+ faster
- String to date: 10x faster
- Object creation: 10x faster
Compared to newer Swift Date conversions (string to date and date to string), for newer versions of iOS:
- Date to string: 50% faster
- String to date: 30% faster
More info on how the benchmark was done is here.
Because it is drop-in, you can simply replace the word NSISO8601DateFormatter with JJLISO8601DateFormatter and add the header include, #import <JJLISODateFormatter/JJLISODateFormatter.h>.
- iOS 10.0+
- MacOS 10.13+
JJLISO8601DateFormatter is available through CocoaPods. To install it, simply add the following line to your Podfile:
pod 'JJLISO8601DateFormatter'It uses the time zone files provided by the system, the same ones that POSIX functions like localtime use. If it can't find them, it will fall back to using Apple's date formatting libraries.
There's nothing special about the library. It is written in straight-forward C and tries to avoid unnecessary allocations, locking, etc. It uses versions of mktime and localtime from tzdb. A better question is, why is Apple's so much slower? Apple's date formatting classes are built on top of ICU, which although reliable, is a fairly slow library. It's hard from a glance to say exactly why, but it seems to have a lot of extra abstraction, needless copying, etc., and in general doesn't prioritize performance as much.
Date formatting is hard. How does this library ensure correctness?
Although date formatting is difficult, this library has an extensive set of unit tests that cover edge cases like:
- All different format options
- All different time zones
- Leap seconds (neither us nor Apple actually handle them)
- Leap days
- Concurrent usage
Things are also easier because, for ISO 8601, we only need to support Gregorian calendar.
For nonsensical format options (week of year but no year) and malformed date strings, the behavior is slightly different. But for all intents and purposes, it is the exact same. Feel free to submit a ticket if you find otherwise.
Because it's easy to type with the left pinky on the shift key.
Yes, there are a lot, the question is which ones are worth optimizing. Feel free to request optimizations for libraries that are causing performance issues for you.
It's done by timing many date to string and string to date conversions across two ranges (15 days before now to 15 days after, from 1970 to now), three time zones, and NSISO8601DateFormatOptionsWithInternetDateTime | NSISO8601DateFormatWithFractionalSeconds for the format options. The benchmark code is located in -viewDidLoad of the Example project's view controller, and you can get nice benchmarking output yourself by running that project. I normally do testing on my iPhone 8, with the occasional double check on other devices. Obviously the numbers can vary.
Contributors are always welcome. Here are some possible improvements:
- Swift version of the library with no Objective-C code
- Full rewrite of NSDateFormatter (doable but is it worth it?)
- Method that returns a
char *instead of anNSStringfor going from date to string. - watchOS and tvOS support
Michael Eisel, [email protected]
JJLISO8601DateFormatter is available under the MIT license. See the LICENSE file for more info.