Re: Need localization-proof method of transporting dates.
Re: Need localization-proof method of transporting dates.
- Subject: Re: Need localization-proof method of transporting dates.
- From: Graham Cox <email@hidden>
- Date: Sun, 5 Apr 2009 19:24:22 +1000
On 05/04/2009, at 5:02 AM, Greg Guerin wrote:
An object's -hash method is not guaranteed to return a unique
value. Different objects can have the same hash as other objects of
the same type, or of different types. Therefore, if you are
calculating a SHA-1 hash of the -hash value returned from the
NSDate, your authentication can be spoofed by an unknown number of
other NSDate objects that return the same value from -hash.
Sure, I understand that. Actually the SHA-1 hash is derived from the -
hash of several objects, not just the date. My take is that the
combination of the several objects (typically about 8 different pieces
of information) is sufficiently unique to be unspoofable in practice.
And in fact the SHA-1 is only used as a signature anyway, not as a
unique value in its own right - the existence of identical SHA-1
hashes for different info sets wouldn't matter.
I suspect that when you write an expiry NSDate to a plist file, it
represents your local date and time. This expiry is then expiring
at your local time, not the recipient's local time. However, since
it's later in your location than almost anywhere else in the world,
the recipient perceives the expiration as premature.
The problem is not in the localization of NSDate. The problem is in
not accounting for time-zone differences between your location and
the user's location.
Nice thought, but not the case. The expiry is firing several months
too early, not just a few hours. While the date written does represent
my local time, the exact expiry would only be affected by a few hours.
I pretty much don't care about that - I don't tell the user to the
second when it will expire anyway, only which day.
However it does seem as if writing out the date as seconds since 1970
(or a string, as Tommy suggested) might be safer and cut out any
potential gotchas that I haven't realised existed.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden