On Apr 4, 2009, at 8:29 AM, Graham Cox wrote:
The date is added to a dictionary. The dictionary is then archived.
Decoding is simply dearchiving.
As long as you're archiving the actual NSDate object, it seems to me
this should be fine. Even if Apple had a bug in the archiving/
unarchiving of NSDate that was sensitive to locale, I would expect
this to affect all your users in a given locale. Is there any way of
telling whether it's correlated with OS version or processor
architecture?
If I wanted to be super-confident/super-paranoid about archiving a
date in a localization-proof way, I'd store the timeIntervalSince1970
rather than the date object itself.
The SHA-1 hash is stored in the same dictionary as NSData. On
decoding I can recover all the objects OK as far as my own testing
can establish - unfortunately getting a debug trace on the tester's
machine is not really possible, so exactly where it's failing I
can't be sure.
The reason I suspect the localisation is that an earlier version
definitely broke with system locale because I was using the -
description method of the date to compute the hash, not the -hash
method, and -description was being formatted according to the system
locale.
Is it possible some of your users are using an archive that uses the
older, buggy storage method? Can they send you the archive file for
dissection?
--Andy
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
