Add support for parse_strings_as_datetimes to expect_column_values_to…

[jcampbell]

Address #422

testing note: I have done a manual test on the sqlalchemy adaptation present here, but unfortunately the sqlite db doesn't handle datetimes well enough to deal with our IN statement required in this case. There may be other idiosyncrasies across different systems as well.

Before merging:
[ ] Review updates to test config to see if it will be possible to either (1) test this using sqlite or (2) migrate testing to a fuller-featured db.

[coveralls]

Coverage decreased (-0.08%) to 94.871% when pulling 0d11698 on fix/values_datetimes into 103b962 on develop.

[coveralls]

Coverage decreased (-0.08%) to 94.871% when pulling 0d11698 on fix/values_datetimes into 103b962 on develop.

[coveralls]

Coverage decreased (-0.08%) to 94.871% when pulling 0d11698 on fix/values_datetimes into 103b962 on develop.

[coveralls]

Coverage increased (+0.01%) to 94.965% when pulling 4586e75 on fix/values_datetimes into 103b962 on develop.

[abegong]

These changes totally make sense.

Do you want to merge this as is, or implement tests against another DB first?

I'd lean towards setting up the DB---travis makes this pretty easy with PostgreSQL, as long as you're hitting a supported version: https://docs.travis-ci.com/user/database-setup/

[jcampbell]

I'd say let's merge these separately...I created a separate branch with its own PR #427 that adds support for testing these against postgres (using travis).

It's good to have the additional detail, because the underlying message is that we're straining the laissez faire GE approach to typing as we are more explicit about additional DB types.

[abegong]

👍