Today I saw this date string out in the wild: 'saturday, 11-jun-2004 16:10:27 GMT'
While looks very much like a date format for which I submitted a patch over a year ago[1], its month starts with a lower-case letter. This string cannot be parsed using apr_date_parse_rfc. I am sure in the myriad of date string specifications there are rules against lower-case month names, but the function in question wants to be lenient in what it parses. I wanted to submit a patch where apr_date_parse_rfc does not care about month cases (achieved by adding a support for a symbol that would match a letter of any capitalization, changing the masks correspondingly, and converting monstr to its usual @$$ form before checking months array), when I noticed that apr_date_checkmask is not a static function and others may use it in a way that would not allow introduction of a new symbol for isalpha[2]. The question therefore becomes, what is the best way to transform apr_date_parse_rfc to support case-insensitive months without sacrificing much performance and breaking the APIs by introducing a new special symbol? One way is to make a maximum of eight calls to apr_date_checkmask instead of one for each format: "@@@" || "@@$" || "@$@"... instead of the current "@$$", but it is just yucky[3]. Given the constraints, I am stuck. Suggestions? - Dmitri. [1] http://cvs.apache.org/viewcvs.cgi/apr-util/misc/apr_date.c?r1=1.15&r2=1.16 [2] From apr_date_checkmask description: <x> - exact match for any other character [3] This could probably be optimized in a loop whose first iteration would catch 99% of cases where month string fits @$$ format, and then, if no matches are found, mangle "@$$" seven more times until something (or nothing) is found.
pgpWHGoV3oGHe.pgp
Description: PGP signature
