Reputation: 1889
Please note that update 3 is probably most relevant
Im setting a NSTimeInterval
property of a managed object with an nsdate object using setValue:forKey:
When i attempt to get the value I get weird stuff, at runtime this
NSLog(@"[managedObject valueForKey:@\"startTime\"] : %@, [NSDate dateWithTimeIntervalSince1970:[managedObject startTime]]: %@",
[managedObject valueForKey:@"startTime"],[NSDate dateWithTimeIntervalSince1970:[managedObject startTime]]);
Returns
[managedObject valueForKey:@"startTime"] : 2012-07-14 08:13:05 +0000,
[NSDate dateWithTimeIntervalSince1970:[managedObject startTime]]: 1981-07-14 08:13:05 +0000
Update 1
The value returned by [managedObject valueForKey:@"startTime"]
is correct. However I would prefer to use [NSDate dateWithTimeIntervalSince1970:[managedObject startTime]]
or something similar so that it is more strongly typed.
I believe [managedObject startTime]
returns an incorrect value => 363954111.000000
.
However i set it with something like this:
managedObject setValue:1342261311 forKey:@"startTime"
It is worth noting that I am unsure whether this is incorrect because [managedObject valueForKey:@"startTime"]
returns a correct NSDate object.
Update 2
I've logged the double values returned by KVC and .
syntax.
managedObject.startTime = 363954111.000000
valueForKey timeIntervalSince1970 = 1342261311.000000
Update 3
Okay, I've set up a test, start time is set like this entity.startTime = [[NSDate dateWithTimeIntervalSince1970:1342261311] timeIntervalSince1970];
and end time is set like this [entity setValue:[NSDate dateWithTimeIntervalSince1970:1342261311] forKey:@"endTime"];
When i write them to log i get this start = 1342261311.000000, end = 363954111.000000
It seems that the NSDate object is being unwrapped incorrectly, has anyone seen this before?
Upvotes: 0
Views: 729
Reputation: 1889
It was a problem with the difference in epochs. NSDate uses Jan 1 2001 as an epoch. So when I was getting the value I was using the unix epoch (1970). That gave me a difference in values.
When KVC unwraps and wraps NSTimeInterval with a NSDate object it uses the NSDate 2001 epoch.
So instead of using dateWithTimeIntervalSince1970
I used dateWithTimeIntervalSinceReferenceDate
when getting the value.
Upvotes: 1
Reputation: 18253
The problem here is that valueForKey:
is intended to be used with object values, in fact it returns an id
.
As a convenience, valueForKey:
wraps primitive types (such as integers and doubles) in their NSNumber
counterparts.
The reason you see two different values is that valueForKey:
returns an id
, which essentially is a pointer to the position in memory where the NSNumber
happens to be stored. Your code then just takes this arbitrary memory address and somehow interprets it as a double and then constructs an NSDate
out of that.
Calling the startTime
accessor method directly, on the other hand, returns the double
without any further ado.
If you want to use valueForKey:
, you can do something like this to get the real value:
NSTimeInterval tiv = [[managedObject valueForKey:@"startTime"] doubleValue];
and then work from there.
I am actually a bit surprised that the compiler doesn't emit a warning about this. Apple's latest compilers have become quite adept at catching problems like this one.
Upvotes: 2
Reputation: 938
If startTime is a NSTimeInterval (and not an NSDate), you are comparing two different things there, a double and an NSDAte object.
[managedObject valueForKey:@"startTime"]
will return you an NSTimeInterval, a primitive (which you should print with %f by the way).
[NSDate dateWithTimeIntervalSince1970:[managedObject startTime]]
will return you a NSDate.
If you really want to comare the two, you should use [NSDate dateWithTimeIntervalSince1970:[managedObject valueForKey:@"startTime"]]
to properly compare two NSDate objects.
Upvotes: 0
Reputation: 7344
NSTimeInterval
is a typdef of a double
typedef double NSTimeInterval;
You can not store scalars directly in core data but you either have to wrap them in a NSNumber
or in your case it may be easier to use a NSDate
.
Upvotes: 0