30x faster JSON date parsing
Parsing dates from strings can be surprisingly expensive — more than once I’ve seen it show up as the primary hot-spot in code that reads files or parses network data. NSDateFormatter is very flexible, but you pay for that in speed. If you only need to parse a single simple date/time format you can do a lot better. A couple of days ago Anrurag Mishra wrote a blog post[1] demonstrating that you can get about 14x faster performance (yes, 14 *times* faster) by calling SQLite’s built-in strftime function. (Actually, my experience is that it’s 30x faster, but I was probably running on different hardware. YMMV.) His code simply compiles and runs a SQL “SELECT” statement that calls strftime — I decided to do better than that by extracting the C code from SQLite that does the actual parsing, and making a direct API for it. That about doubles performance again. Here are some benchmark results (run on a 2012 MacBook Pro): [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:42.709| [fg0,128,0;[;sqlite3 strftimetook 0.89 µsec (30x) [fg160,160,160;16:34:46.788| [fg0,128,0;[;-dateWithJSONObject took 0.68 µsec (40x) [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) (Here CBLParseDate is the raw function that returns a UNIX timestamp, and -dateWithJSONObject is a wrapper method that returns the same time as an NSDate object, which of course has extra overhead.) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like “2013-09-09T17:52:12Z”. It’s certainly possible to munge this code to parse a slightly different format, but you’re on your own there! You can grab my code (which is just a hack-and-slash of Richard Hipp’s SQLite code) from the Couchbase Lite repo[2]. It has no dependencies on anything but the C standard library, so it should be easy to drop into your own projects. [1] http://vombat.tumblr.com/post/60530544401/date-parsing-performance-on-ios-nsdateformatter-vs [2] https://github.com/couchbase/couchbase-lite-ios/blob/master/Source/CBLParseDate.c ___ 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
Re: 30x faster JSON date parsing
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. On Sep 10, 2013, at 0:11, Jens Alfke j...@mooseyard.com wrote: Parsing dates from strings can be surprisingly expensive — more than once I’ve seen it show up as the primary hot-spot in code that reads files or parses network data. NSDateFormatter is very flexible, but you pay for that in speed. If you only need to parse a single simple date/time format you can do a lot better. A couple of days ago Anrurag Mishra wrote a blog post[1] demonstrating that you can get about 14x faster performance (yes, 14 *times* faster) by calling SQLite’s built-in strftime function. (Actually, my experience is that it’s 30x faster, but I was probably running on different hardware. YMMV.) His code simply compiles and runs a SQL “SELECT” statement that calls strftime — I decided to do better than that by extracting the C code from SQLite that does the actual parsing, and making a direct API for it. That about doubles performance again. Here are some benchmark results (run on a 2012 MacBook Pro): [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:42.709| [fg0,128,0;[;sqlite3 strftimetook 0.89 µsec (30x) [fg160,160,160;16:34:46.788| [fg0,128,0;[;-dateWithJSONObject took 0.68 µsec (40x) [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) (Here CBLParseDate is the raw function that returns a UNIX timestamp, and -dateWithJSONObject is a wrapper method that returns the same time as an NSDate object, which of course has extra overhead.) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like “2013-09-09T17:52:12Z”. It’s certainly possible to munge this code to parse a slightly different format, but you’re on your own there! You can grab my code (which is just a hack-and-slash of Richard Hipp’s SQLite code) from the Couchbase Lite repo[2]. It has no dependencies on anything but the C standard library, so it should be easy to drop into your own projects. [1] http://vombat.tumblr.com/post/60530544401/date-parsing-performance-on-ios-nsdateformatter-vs [2] https://github.com/couchbase/couchbase-lite-ios/blob/master/Source/CBLParseDate.c ___ 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/xcvista%40me.com This email sent to xcvi...@me.com ___ 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
Re: 30x faster JSON date parsing
Le 9 sept. 2013 à 18:11, Jens Alfke j...@mooseyard.com a écrit : Parsing dates from strings can be surprisingly expensive — more than once I’ve seen it show up as the primary hot-spot in code that reads files or parses network data. NSDateFormatter is very flexible, but you pay for that in speed. If you only need to parse a single simple date/time format you can do a lot better. A couple of days ago Anrurag Mishra wrote a blog post[1] demonstrating that you can get about 14x faster performance (yes, 14 *times* faster) by calling SQLite’s built-in strftime function. (Actually, my experience is that it’s 30x faster, but I was probably running on different hardware. YMMV.) His code simply compiles and runs a SQL “SELECT” statement that calls strftime — I decided to do better than that by extracting the C code from SQLite that does the actual parsing, and making a direct API for it. That about doubles performance again. Here are some benchmark results (run on a 2012 MacBook Pro): [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:42.709| [fg0,128,0;[;sqlite3 strftimetook 0.89 µsec (30x) [fg160,160,160;16:34:46.788| [fg0,128,0;[;-dateWithJSONObject took 0.68 µsec (40x) [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) (Here CBLParseDate is the raw function that returns a UNIX timestamp, and -dateWithJSONObject is a wrapper method that returns the same time as an NSDate object, which of course has extra overhead.) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like “2013-09-09T17:52:12Z”. It’s certainly possible to munge this code to parse a slightly different format, but you’re on your own there! You can grab my code (which is just a hack-and-slash of Richard Hipp’s SQLite code) from the Couchbase Lite repo[2]. It has no dependencies on anything but the C standard library, so it should be easy to drop into your own projects. Isn't it possible to parse it using the libc function strftime ? How does it compare to the other solutions ? -- Jean-Daniel ___ 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
Re: 30x faster JSON date parsing
Hi Jens, Premature optimization is the root of all evil! Er, I misspelled: “very cool, nice job!” On Sep 9, 2013, at 18:11 , Jens Alfke j...@mooseyard.com wrote: [..] [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like “2013-09-09T17:52:12Z”. That might actually be a feature. (Also: didn’t know ISO did informal standards…) [1] http://vombat.tumblr.com/post/60530544401/date-parsing-performance-on-ios-nsdateformatter-vs [2] https://github.com/couchbase/couchbase-lite-ios/blob/master/Source/CBLParseDate.c Marcel ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 19:05 , Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 18:11, Jens Alfke j...@mooseyard.com a écrit : [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) Isn't it possible to parse it using the libc function strftime ? How does it compare to the other solutions ? If I read it correctly, 3-8 times slower than using SQLite, so I guess 6-16 times slower than Jens’s code. https://news.ycombinator.com/item?id=6344746 Marcel ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 19:20 , Tito Ciuro tci...@mac.com wrote: On Sep 9, 2013, at 10:14 AM, Marcel Weiher marcel.wei...@gmail.com wrote: Premature optimization is the root of all evil! What's premature about it? Nothing: Er, I misspelled: “very cool, nice job!” :-) Marcel ___ 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
Re: 30x faster JSON date parsing
What's premature about it? -- Tito On Sep 9, 2013, at 10:14 AM, Marcel Weiher marcel.wei...@gmail.com wrote: Hi Jens, Premature optimization is the root of all evil! Er, I misspelled: “very cool, nice job!” On Sep 9, 2013, at 18:11 , Jens Alfke j...@mooseyard.com wrote: [..] [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like “2013-09-09T17:52:12Z”. That might actually be a feature. (Also: didn’t know ISO did informal standards…) [1] http://vombat.tumblr.com/post/60530544401/date-parsing-performance-on-ios-nsdateformatter-vs [2] https://github.com/couchbase/couchbase-lite-ios/blob/master/Source/CBLParseDate.c Marcel ___ 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/tciuro%40mac.com This email sent to tci...@mac.com ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 19:35 , Jens Alfke j...@mooseyard.com wrote: On Sep 9, 2013, at 10:14 AM, Marcel Weiher marcel.wei...@gmail.com wrote: Premature optimization is the root of all evil! I’m not sure if you meant that ironically, but it’s absolutely not premature. Absolutely! On both counts. It just seems to be the appropriate response on this mailing list for measured improvements to significant bottlenecks in the 4x - 50x range :-) 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, Oh yes, I’ve also seen it a bunch of times, and it is so slow it doesn’t have to occur many times to actually be noticeable. So again: On Sep 9, 2013, at 19:14 , Marcel Weiher marcel.wei...@gmail.com wrote: Er, I misspelled: “very cool, nice job!” Cheers, Marcel ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 10:14 AM, Marcel Weiher marcel.wei...@gmail.com 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 xcvi...@me.com 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 (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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 11:35 AM, Jens Alfke j...@mooseyard.com wrote: 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. Me too. In my case, there was a lot of redundancy, and I use a lot of C++ and low-level C already, so I got a huge performance gain just from mapconst char *, double, staticFuncThatCallsStrCmp to cache values as they were parsed... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander jgo...@yahoo.com wrote: The issue is users entering dates […] am sorely wishing I could just enforce ISO date entry as in the quoted example by using pop-up menus. Some do, but the dread of customer rebellion is strong, and they want to enter them in the slap-dash, hurried, harried ways they're used to writing them, or finding them in their source materials. You’re mixing this up with a totally different issue. *Users* should be able to enter dates however the hell they want. The computer is the user’s servant, not the other way around*. Yes it can be awkward to parse natural-language dates, but it’s pretty much a solved problem. I really appreciate software like Fantastical and Siri that lets me type/say stuff like “next tue 3pm”. *Data formats* should use strict standards for dates. I spent several years working on RSS clients and RSS parsing, and you would not believe the kind of crap people put into their feeds as post dates. I even ran into feeds that forgot to turn off localization so the dates came out like “Freitag, 27 Juli”. We ended up with an array of 20+ format strings and had to loop through them until one of them could parse the string. (Of course it didn’t help that the RSS “specs” were hopelessly vague and for a long time there wasn’t a validator.) These are of course unrelated issues because no one would put unparsed user-input date strings into a well-defined file format. Right? MSFT Javascript (and it's non-standards) is evil, hence, JSON is evil. Huh? Microsoft doesn’t drive JavaScript (although they had some say in the ECMAscript standardization.) Mozilla has more influence than they do. And JSON isn’t tied to JavaScript, it just happens to look like the syntax JS uses to express object trees. (It’s 99% the same as Python, for example.) —Jens * Related: there’s a special circle in Hell for web coders too lazy to write a regexp that allows users to enter a credit card number with spaces or dashes in it. ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 09:25 , Maxthon Chan xcvi...@me.com 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. Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or other human-readable format) dates. -- Rick ___ 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
Re: 30x faster JSON date parsing
Just to add a tiny wrinkle: On Sep 9, 2013, at 20:27 , Jens Alfke j...@mooseyard.com wrote: On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander jgo...@yahoo.com wrote: [..] Some do, but the dread of customer rebellion is strong, and they want to enter them in the slap-dash, hurried, harried ways they're used to writing them, or finding them in their source materials. You’re mixing this up with a totally different issue. *Users* should be able to enter dates however the hell they want. [] Yes it can be awkward to parse natural-language dates, but it’s pretty much a solved problem. I really appreciate software like Fantastical and Siri that lets me type/say stuff like “next tue 3pm”. And performance isn’t really that critical for user entry on a single user machine, unless you’re a much faster typist than I am. :-) So turn all the heuristics and sophisticated processing when you are receiving user input and then store it in a standardized format.. *Data formats* should use strict standards for dates. [rss horror stories] …that can be parsed efficiently and reliably. And no, in my experience just storing Unix time or some other well-defined UTC time is not enough for many use-cases, you actually want to know the local time the user intended. For example, you don’t probably don’t want to have per-day processing kicked off at midnight zulu if you are on the west coast, and you want that to change if the machine is moved. These are of course unrelated issues because no one would put unparsed user-input date strings into a well-defined file format. Right? *g* Marcel ___ 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
Re: 30x faster JSON date parsing
On 9 Sep 2013, at 20:29, Rick Mann rm...@latencyzero.com wrote: On Sep 9, 2013, at 09:25 , Maxthon Chan xcvi...@me.com 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. Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or other human-readable format) dates. Yes, it absolutely is, when no human is going to read them. Tom Davie ___ 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
Re: 30x faster JSON date parsing
On Sep 9, 2013, at 11:46 , Tom Davie tom.da...@gmail.com wrote: On 9 Sep 2013, at 20:29, Rick Mann rm...@latencyzero.com wrote: On Sep 9, 2013, at 09:25 , Maxthon Chan xcvi...@me.com 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. Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or other human-readable format) dates. Yes, it absolutely is, when no human is going to read them. No human (user) *should* be reading data like that unmodified out of JSON. It's not enough to claim it makes development easier. But pre-formatting the strings for direct display guarantees a parsing requirement for a great many consumers. Date formats vary widely based on localization and the elegance of the UI (relative dates, for example, require parsing and then math). I'm generally opposed to non-binary protocols at all, but it's made worse when you have to parse something like a formatted date, especially when there's no guarantee of stability. -- Rick ___ 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
Re: 30x faster JSON date parsing
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. +1 I've encountered a lot of performance issues due to NSDateFormatter, specifically when used with RestKit and parsing JSON responses. ___ 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
Re: 30x faster JSON date parsing
On 2013 Sep 09, at 13:14, Marcel Weiher wrote: On 2013 Sep 9, at 18:11 , Jens Alfke j...@mooseyard.com wrote: [...] [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47 µsec (58x) Now, the tradeoff is that the optimized code parses only ISO 8601 dates — this is the informal standard used with JSON, so it’s become really common. It looks like 2013-09-09T17:52:12Z”. That might actually be a feature. (Also: didn’t know ISO did informal standards…) Looks like a feature, to me. The issue is users entering dates -- Julian (as in pre-Gregorian/old style, not yyddd), day of week, month and year (i.e. incomplete dates, e.g. from grave-stones which were shot up in a war missing individual digits, or chemical break-down of the material), Hebrew calendar, Muslim calendar, Chinese, Japanese... with variant orders of the parts, variant punctuation, etc., leap seconds, expressions like noon or nones, first bell of the third watch (?)... even just typographical errors... It at first seems like it should be sooo simple, but it is not. I go into analysis paralysis just thinking about it... and am sorely wishing I could just enforce ISO date entry as in the quoted example by using pop-up menus. Some do, but the dread of customer rebellion is strong, and they want to enter them in the slap-dash, hurried, harried ways they're used to writing them, or finding them in their source materials. Near-perfection, even satisficing, in interpreting such is expensive. MSFT Javascript (and it's non-standards) is evil, hence, JSON is evil. Further deponent saith nought. ___ 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
