hotfix for the date formatting issue

[pgulley]

Kind of breaks the abstraction pattern, but I think it's fine for this case- dates just need a separate formatter in the es_client. Validated in a dev stack.

[philbudne]

In the dark here, 'cause I don't know much about the code, or the bug, and I know this is code that came from IA, and this is marked "hotfix", so I imagine there is some urgency.... but:

1. There another invocation of format_counts (in get_terms) does this apply there?
2. To me, it's hard to see the difference between the two branches of the "if", and it might be more compact, and clearer if there was one function, that took the aggregation type (either as a string or as a bool) and returned the right thing.
3. my_dict.update({key: ....}) is less clear to me than my_dict[key] = ... but maybe that's just me?????

[pgulley]

In the dark here, 'cause I don't know much about the code, or the bug, and I know this is code that came from IA, and this is marked "hotfix", so I imagine there is some urgency.... but:

1. There another invocation of `format_counts` (in `get_terms`) does this apply there?

2. To me, it's hard to see the difference between the two branches of the "if", and it might be more compact, and clearer if there was one function, that took the aggregation type (either as a string or as a bool) and returned the right thing.

3. `my_dict.update({key: ....})` is less clear to me than `my_dict[key] = ...` but maybe that's just me?????

Agree about the functional formatting- simplified per those notes!
The other instance in the top_terms path shouldn't apply here!