Add Date in days conversion support

[wamsiv]

@andrewseidl Need to tag docker core build with latest commits in it, to enable the commented tests, they are failing on current build: v4.5.0dev-20190104-5aee66d0e5

fixes #167

[randyzwitch]

Shouldn't need a print() statement here

[wamsiv]

Forgot to remove it! Thanks!

[randyzwitch]

@wamsiv Since this issue started with OmniSci 4.4, why wouldn't we expect this functionality pass on any build?

[wamsiv]

We started exposing encoding to end points recently through a commit which is not available in this build. Without that there is not no way of knowing days/seconds type.

[randyzwitch]

I guess what I'm asking is if the tests require a certain version of OmniSci, do we need to add some sort of OmniSci version logic into pymapd either in connect() or into the table loading code? It feels like we're breaking backwards compatibility unnecessarily, instead of fixing something that the user shouldn't need to worry about.

[wamsiv]

Looks like latest build container is failing at the start. And we are not breaking any compatibility, here I have added: https://github.com/omnisci/pymapd/pull/168/files#diff-51b57568ea5bfd539fbcf96d15ad4b18R86 another condition for date encoding in days. The legacy dates will still pass through date_to_seconds(data).

[wamsiv]

@randyzwitch Ok I think I understand what you are confused about here. So, now the new columns which are getting created have encoding in days. If you try to use load_table here on new dates it would expect the input in days, which my logic does here but problem is that we were not exposing the encoding of new DATE type before. heavyai/heavydb@99adcec now exposes the end point, which is not available in 4.4.2 hence when loading the data through load_table_columnar since we do not receive proper encoding for the type it assumes that encoding is NONE and proceeds to insert value in seconds (legacy way) rather than using new days logic.

[randyzwitch]

Ok, so it's 4.4.2 that unintentionally broke the compatibility by not exposing the endpoint? If so, can't do anything about that now.

This is failing because the newest version for Docker is still 4.4.2. @andrewseidl, if you could ping us when 4.5 is available, then we can merge this PR and get a new version of pymapd out the door

[wamsiv]

v4.5.0 is available as the latest build and runs fine on local. Looks like this is a system issue, not with our container.

[randyzwitch]

LGTM, passes on my local machine. Needed to run docker run --ipc=host -d -p 9091:6274 mapd/core-os-cpu due to port remapping (per #163)