billymeltdown / nsdate-helper Goto Github PK

It's bad practice to create new instance of NSDateFormatter every time, when I call method. Creation of this object is too expensive. From Apple Data Formatting Guide:

Creating a date formatter is not a cheap operation. If you are likely to use a formatter frequently, it is typically more efficient to cache a single instance than to create and dispose of multiple instances. One approach is to use a static variable.

User denvog reports:

I noticed last week in the Kevin Smith App that some of my dates handled with NSDate+Helper are now jumping a year. It looks like everything in the last week of December/first week of January. For example, a post on Dec 29, 2009 is showing as Dec 29, 2010. While Dec 25 is showing correctly as 2009.

I've done a bunch of logging, and the source data coming in is correct with 2009.

It looks like it is items calling stringForDisplayFromDate

So I think the fix is to change line 129 of NSDate+Helper.m from
[displayFormatter setDateFormat:@"MMM d, YYYY"];

                           [displayFormatter setDateFormat:@"MMM d, yyyy"];

According to this thread there is a difference in calendar as of day, as opposed to calendar year as of week.
http://www.iphonedevsdk.com/forum/iphone-sdk-development/8355-date-formatting-yyyy-vs-yyyy-getting-wrong-year.html

If the first use of the library is a call to stringWithFormat then nil is returned. This is happening because the static date formatter has not been initialized in this case.

I'm not really sure why I didn't do this in the first place, but this would be a lot easier to use and look a tad nicer if I implemented something like:

NSDate *date = [NSDate date];
NSString *dbString = [date string];
NSString *formattedString = [date stringWithFormat:@"yyyy"];

That last one strikes me as nice-to-have and possibly over-complicating things, but definitely need to get some instance methods going here to replace the need to call class methods in a clumsier fashion, e.g.:

NSString *dbString = [NSDate stringFromDate:date];
NSString *formatted = [NSDate stringFromDate:date withFormat:@"yyyy"];

We've had bugs emerge in Codebook and Strip, where I use NSDate+Helper heavily, since the introduction of a static NSCalendar variable in this category's +load implementation. This can be seen with a little NSLog output on the Console in Release configuration on iOS 5.1:

Mar 28 10:59:43 unknown Codebook[11773] <Warning>: date in question: 2012-03-27 19:47:09 +0000
Mar 28 10:59:43 unknown Codebook[11773] <Warning>: today is: 2012-03-28 14:59:43 +0000
Mar 28 10:59:43 unknown Codebook[11773] <Warning>: midnight based on today and calendar components: (null)
Mar 28 10:59:43 unknown Codebook[11773] <Warning>: shared calendar object? (null)

I believe load is not being called at the same time in Release configuration for this category as it is for Debug configuration, and something about when it is being called results in the static calendar variable being null. It could be that there was no 'currentCalendar' when the category was originally loaded (likely not when my view was loaded above). While this was introduced for performance, it's not working in Release, going to have to remove the static variable for now. Open to other ideas, especially if anybody (Jim?) wants to dig into why +load isn't being called at the same time and how we could approach this differently. FWIW, performance doesn't appear to be too bad, I'd be curious to see any metrics demonstrating particularly poor performance (I hadn't noticed any issues myself before this change was introduced).

I’ve recently added NSDate+Helper to the CocoaPods package manager repo.

CocoaPods is a tool for managing dependencies for OSX and iOS Xcode projects and provides a central repository for iOS/OSX libraries. This makes adding libraries to a project and updating them extremely easy and it will help users to resolve dependencies of the libraries they use.

However, NSDate+Helper doesn't have any version tags. I’ve added the current HEAD as version 0.0.1, but a version tag will make dependency resolution much easier.

Semantic version tags (instead of plain commit hashes/revisions) allow for resolution of cross-dependencies.

In case you didn’t know this yet; you can tag the current HEAD as, for instance, version 1.0.0, like so:

$ git tag -a 1.0.0 -m "Tag release 1.0.0"
$ git push --tags

Is there any plan to support more language, like spanish?

So, the code in this little module has been simply (C) Zetetic LLC since we put it up here. In the interests of 1) making it actual open source code and 2) kindly asking others to credit the authors (in this regard, I hope it will encourage others to contribute), I'm planning on adding an actual license to the project.

I intend to use exactly the same one we use for sjlombardo/sqlcipher, unless anybody objects. It's nearly identical to the MIT-style license used by many Ruby projects, and we think it's appropriate. I'm certainly open to other ideas, please feel free to comment.

http://github.com/sjlombardo/sqlcipher/blob/master/README

Regards,
Billy

This works great for english, but when the device is under another language it stills trows dates in english.

CocoaPods is awesome, why don't you use it?