https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6152
--- Comment #7 from Karsten Bräckelmann <guent...@rudersport.de> 2009-07-10
11:10:02 PST ---
OK, more constructive comments. A better version should be this RE:
/[-+](?:[2-9]\d\d\d|1[5-9]\d\d|\d\d(?:[25-9]\d|[03][^0]|[14][^5]))$/
Unless negative look-ahead assertions do have a significant performance impact,
we could even do it the other way round and actually define what we consider to
be a sane offset. Like this.
/[-+](?!(?:0\d|1[0-4])(?:[03]0|[14]5))\d{4}$/
This looks out for a four digit offset, that does not match the sane offsets
defined in the leading (?! ) part. Probably better comprehensible, apart from
the reversed logic. ;)
This one is my proposal.
Being slightly more anal, cutting off at +1400, not allowing 14-odd fractions
either, would just bloat the RE and isn't worth it IMHO. Same for
differentiating further between positive and negative possible offsets.
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
