On Mar 31, 2014, at 12:04 , D. Felipe Torres <warorf...@gmail.com> wrote:
> I found out it only fails under my current timezone: I went to stackoverflow to read the outcome, and for completeness I’ll report here that the above isn’t true. It doesn’t fail under your particular timezone. It fails under *any* timezone, if the specified time is invalid — if the time is within the hour that’s skipped during a transition into daylight savings time. The “fix" you describe there isn’t a fix at all, because (at least) it lies to the user. The real problem is that the string you’re trying to interpret is flat out invalid, and there seem to me to be two possible solutions: 1. If you insist on interpreting the string as a date, then you must solve the problem upstream of the NSDataFormatter conversion. That is, you must ensure that the string is valid before you feed it to NSDateFormatter. 2. If all you care about is interpreting the string as a data description (that is, something formatted like a date but not necessarily having a valid set of numbers) then you should scan the string as text and break it into components textually. If you want to localize the result according to the user’s date/time preferences, there may be a route involving NSCalendarComponents, but you’d need to deal with potential error returns each step of the way. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
