Extend meta_df tests to include datetime

[znicholls]

Please confirm that this PR has done the following:

• Tests Added
• Documentation Added (N/A)
• Description in RELEASE_NOTES.md Added

Adding to RELEASE_NOTES.md (remove section after adding to RELEASE_NOTES.md)

Please add a single line in the release notes similar to the following:

- (#XX)[http://link-to-pr.com] Added feature which does something

Description of PR

Closes #222. Good news is this was already sorted in v0.2.0 so all this does is make sure it stays that way by expanding the tests a bit.

[coveralls]

Coverage increased (+0.2%) to 92.009% when pulling 6b5688d on znicholls:move-idx-definitions into a73fc6a on IAMconsortium:master.

[coveralls]

Coverage increased (+0.2%) to 92.022% when pulling 5cbcb42 on znicholls:move-idx-definitions into 25aa7f0 on IAMconsortium:master.

[danielhuppmann]

thanks @znicolls for extending the tests - important steps towards full support of datetime!

one request to add a sanity check on the new `swap_time_for_year()´ function, and some suggestions for a more concise notation in the tests.

[znicholls]

cheers @danielhuppmann, that should all be addressed now!

[znicholls]

not sure what's going on with CI, read through pyproj4/pyproj#134 but am none the wiser...

[danielhuppmann]

sorry about this - @gidden and I already discussed that the region-plotting-tests are quite unstable. How about deactivating those for Windows machines?

[gidden]

Hi folks - indeed these are our most finicky tests. One suggestion before turning them off for windows.

In pyproj4/pyproj#134, someone notes that the issue goes away for pyproj>2.1.

On appveyor, I see that the version is:

pyproj: 1.9.6

So perhaps we can try adding the minimum version to our appveyor install?

If that still fails, then I'm ok with just turning them off on windows..

[gidden]

Hey @znicholls, I'm now digging through more geopandas/cartopy/pyproj issues. I have two thoughts.

First is related to geopandas/geopandas#830, which suggests a specific pyproj version for windows. To attempt this, can you please revert the update in ci/environment-conda-forge.txt and try pinning only the appveyor install to "pyproj=1.9.4"?

Second, I'm looking through our last successful CI on windows: https://ci.appveyor.com/project/gidden/pyam/builds/24523793/job/2idsdm0hhgvg2tfw

In reviewing the package versions at runtime, there is no difference between that run and 60ccc9a. In reviewing the installed conda packages, however, I see the following difference:

Successful run:

proj4                     5.2.0                ha925a31_1 

Failed run:

proj4                     5.2.0             h6538335_1002    conda-forge

Thus this implies one potential fix is to install proj4 via the first conda install (without -c conda-forge).

I know this is annoying, but if you would be willing to try those two changes, that would be amazing. Otherwise, let's just turn this stuff off for windows.

[gidden]

I don't know whether to be happy or sad, but it looks fixed now!

[gidden]

A few inline comments, then this is g2g for me. @danielhuppmann you still have this blocking in review, so let us know if it passes muster!

[gidden]

Looks great! I'll let @danielhuppmann pull this one in.

[danielhuppmann]

thanks @znicholls