How should times with parentheses around the acronym be handled?

[lavelle]

It would be trivial to just add an optional opening parenthesis before and an optional closing one after, but this would mean that strings like "8:32 (GMT" would be valid.

This could be a good thing, converting times where people have typed sloppily, but it could introduce more bugs.

It would be more difficult to enforce having either both parentheses or neither. I'm not sure you can do this with regular expressions, apart from having the entire list of acronyms in there twice, once with parentheses around and once without. This seems like it would run at half the speed, and would also not be very scalable (do we add the list a third time to support square brackets?)

Other solutions, like incrementing a counter for every opening parenthesis and decrementing it for every closing one and checking if the total for the string is zero also sound slow, and overkill for a relatively rare format.

It seems like the best solution is to just support unmatched parentheses, but then if we add square brackets in future it would allow strings like "10:32 [GMT)".

Again, debatable whether this is a good thing or not. I'm leaning towards just allowing them unmatched, and reconsidering if it causes any problems.

[olane]

Yep, as far as I'm aware the only way to do this with a regular language (like regular expressions) is to basically compose two regexes, one with the brackets and one without, and put a | in the middle. Doesn't scale well.

I can't think of any serious bugs that would be caused by allowing mismatched or unbalanced brackets, and they're unlikely to even come up. We should, though, make sure the last bracket matcher is greedy, so we don't end up just not matching the last bracket because it's optional and leaving it trailing after converting the time.

The only place where this might break that I can think of is at the end of some brackets that aren't part of the time. If we scan the string "..when the event finishes (at 6PM EST).", then we'll end up with a converted time like "...when the event finishes (at 11PM BST.".

I think the worst that can come out of this is unbalancing existing brackets, which I think is a minor bug. On the other hand, I don't know if there would be any appreciable difference in speed to parse the brackets separately. On balance, I agree - probably best to just allow unmatched brackets for now.