Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added millisecond support for NSDate objects #123

Closed
wants to merge 2 commits into from

Conversation

scottadav
Copy link

JSONModel was failing to parse NSDate values with milliseconds, for example "2013-11-27T05:00:00.000Z". I created a fork of JSONModel and made a fix, including an additional unit test case. Could you please review it and pull it into the main project if it looks good?

Thanks,
Scott

@billinghamj
Copy link
Member

Seems like an odd way of doing it.

I think it may be more appropriate to implement a parsing method which is more flexible - allowing just dates without times, etc. also

@icanzilb
Copy link
Collaborator

well it's partially my fault, because I didn't provide a complete iso parser in first place, but I can't merge ifs for each variation of the ios specification either ...

@billinghamj
Copy link
Member

Is there a parsing method which doesn't rely on using a date formatter?


Sent from my iPhone

On Tue, Nov 12, 2013 at 11:03 PM, Marin Todorov notifications@github.com
wrote:

well it's partially my fault, because I didn't provide a complete iso parser in first place, but I can't merge ifs for each variation of the ios specification either ...

Reply to this email directly or view it on GitHub:
#123 (comment)

@icanzilb
Copy link
Collaborator

looks like a simple regex will take care of it. I was considering including an iso date parser as a submodule, but in the end I'd rather not have automatic dates than having a submodule

@scottadav
Copy link
Author

Thanks for taking a look at this!

Poking around, I found the following project for iso date parsing:

https://github.com/boredzo/iso-8601-date-formatter

It would create a library dependency for JSONModel, but at least it's available in CocoaPods.

Another, more flexible, option would be to allow the user to override the date format string to use. That way even non-ISO compliant dates could be used. Compliant date formats are better of course, but when writing a client for an existing API, there isn't always the option of having the API's maintainer fix their design.

Even more flexible than that, the user could be allowed to provide a custom NSDateFormatter object. That way I could use ISO8601DateFormatter without having to create a library dependency for JSONModel.

I updated my own branch of JSONModel to use the ISO8601DateFormatter library directly. There were several changes to support pulling in a library from Cocoapods, but really the only files that changed were JSONValueTransformer.m and JSONModel.podspec. The branch path is https://github.com/scottadav/JSONModel/tree/dates_with_millisec .

Thanks,
Scott

On 11/12/13 4:18 PM, Marin Todorov wrote:

looks like a simple regex will take care of it. I was considering including an iso date parser as a submodule, but in the end I'd rather not have automatic dates than having a submodule


Reply to this email directly or view it on GitHubhttps://github.com//pull/123#issuecomment-28344030.

@icanzilb
Copy link
Collaborator

Scott ... there are a number of ways you can override the date conversions.
If you want to support a different date format in all your models have a look at this one:
http://www.touch-code-magazine.com/JSONModel#customtransofrmers

@scottadav
Copy link
Author

That worked. Thanks for the tip.

@interface JSONValueTransformer (NSDate)
-(NSDate_)NSDateFromNSString:(NSString_)string;
@EnD

@implementation JSONValueTransformer (NSDate)
-(NSDate_)NSDateFromNSString:(NSString_)string
{
ISO8601DateFormatter *dateFormatter = [[ISO8601DateFormatter alloc] init];
NSDate *date = [dateFormatter dateFromString:string];
return date;
}
@EnD

Regards,
Scott

On 11/13/13 2:10 PM, Marin Todorov wrote:

Scott ... there are a number of ways you can override the date conversions.
If you want to support a different date format in all your models have a look at this one:
http://www.touch-code-magazine.com/JSONModel#customtransofrmers


Reply to this email directly or view it on GitHubhttps://github.com//pull/123#issuecomment-28434073.

@icanzilb icanzilb closed this Apr 16, 2014
@billinghamj
Copy link
Member

@icanzilb What about adding a dependent cocoapod for the date formatting? I've started using the ISO8601DateFormatter in my pods and it's working nicely

@icanzilb
Copy link
Collaborator

if there's a condition checking at runtime if the cocoa pod is available so JSONModel can work also without the ISO8601DateFormatter ... this could be a go

@billinghamj
Copy link
Member

Ah, that would be a great solution. The only thing is that without the use of #imports, the selector/class code will be messy

@icanzilb
Copy link
Collaborator

the thing is I still love it that you can just download JSONModel as a zip file from github, easy peasy ... adding dependancies on other cocoa pods, etc will force everyone to use cocoapods and I don't want to do that

@billinghamj
Copy link
Member

That is true, though I think if not cocoapods, most people use submodules. If it was done cleverly based on presence, that would be nice.

@ghost
Copy link

ghost commented Feb 3, 2016

hi, i'm a big problem. The api tha i'm calling has the date formatter:
"start_date":"2016-02-02T06:59:17.000+01:00"

how can put the value in an NSDate *start_date of JSONModel ?

@billinghamj
Copy link
Member

Er, that format should work - it is valid in the ISO8601 spec. Is it currently rejected?

@billinghamj
Copy link
Member

To be honest, I think we should bite the bullet and include a dependency. That's @icanzilb's call though.

@billinghamj
Copy link
Member

Or alternatively include the files in JSONModel with some kind of prefix to prevent collision.

@billinghamj
Copy link
Member

See #437.

@ghost
Copy link

ghost commented Feb 3, 2016

Suppose for a moment that the format of my date is not iso8601 .. I read the documentation.. you can use these methods. Where they should be placed?

`@implementation JSONValueTransformer (CustomTransformer)

  • (NSDate )NSDateFromNSString:(NSString)string {
    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
    [formatter setDateFormat:APIDateFormat];
    return [formatter dateFromString:string];
    }
  • (NSString *)JSONObjectFromNSDate:(NSDate *)date {
    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
    [formatter setDateFormat:APIDateFormat];
    return [formatter stringFromDate:date];
    }

@end`

@billinghamj
Copy link
Member

You could do that. The code for that can be anywhere in your project.

It might be better to use a custom setter in that case though - otherwise you're overriding NSDate serialization for every use of JSONModel in your entire project (including dependencies).

@fergalrooney
Copy link

@billinghamj Can you give an example of the custom setter you a referring to? Are you suggesting adding a custom setter on the NSDate property on the JSONModel subclass?

@billinghamj
Copy link
Member

@fergalrooney e.g.:

- (void)setSomeDateWithNSString:(NSString *)string
{
  self.someDate = [ISO8601 parse:string];
}

@fergalrooney
Copy link

@billinghamj Ahhh, gotcha. So make the JSONModel property a string and add a new property for your date representation...

@billinghamj
Copy link
Member

@fergalrooney Nope - the property doesn't need to change at all. It would still be an NSDate. JSONModel just checks whether you have some custom logic for setting the date before doing it automatically.

For completeness:

@interface MyClass : JSONModel

@property (nonatomic, strong) NSDate *someDate;

@end
@implementation MyClass

- (void)setSomeDateWithNSString:(NSString *)string
{
  self.someDate = [ISO8601 parse:string];
}

@end

Then to use it:

NSString *json = @"{\"someDate\": \"2016-01-01T00:00:00Z\"}";
MyClass *obj = [[MyClass alloc] initWithString:json];

// obj.someDate is now an NSDate representing 1st Jan 2016

@fergalrooney
Copy link

@billinghamj Fantastic. Appreciate the help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants