On Sep 9, 2013, at 10:14 AM, Marcel Weiher <[email protected]> wrote:
> Premature optimization is the root of all evil! I’m not sure if you meant that ironically, but it’s absolutely not premature. I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the time to open this file is spent inside NSDateFormatter” — at least twice, and the author of the blog post I linked to says that he also found it to be a major performance issue in data parsing. It also comes up periodically on the CouchDB mailing list in discussions of slow database indexing. > That might actually be a feature. (Also: didn’t know ISO did informal > standards…) It’s only a de-facto standard in JSON — the JSON spec says nothing about dates because they’re not a first-class data type. I think it was adopted because ISO-8601 is pretty well supported in most flavors of JavaScript/ECMAScript. On Sep 9, 2013, at 9:25 AM, Maxthon Chan <[email protected]> wrote: > This may not be that useful in all circumstances - I always send dates as > milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way* > faster to parse. Amen, brother. But you often can’t control the format of the data you parse. And some people find it valuable to use human-readable dates. —Jens _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
