fixed schema violation for timestamp with tz#260
Conversation
|
The black code formatter is causing tests to be red. I suggests you install the pre-commit hooks or run |
fjetter
left a comment
There was a problem hiding this comment.
Thanks for your contribution!
Overall LGTM. Can you add an entry to the changelog, please? see https://github.com/JDASoftwareGroup/kartothek/blob/master/CHANGES.rst
Allow dask_index_on for all col types
…I have added extra dt cols
Codecov Report
@@ Coverage Diff @@
## master #260 +/- ##
==========================================
+ Coverage 89.72% 89.84% +0.11%
==========================================
Files 39 39
Lines 3729 3741 +12
Branches 906 909 +3
==========================================
+ Hits 3346 3361 +15
+ Misses 224 223 -1
+ Partials 159 157 -2
Continue to review full report at Codecov.
|
|
Tests are now passing for pyarrow 0.15 and 0.16 I have done an investigation into earlier pyarrow versions, how they store schema internally appears to be significantly different from later versions. I could not pinpoint it to the changelog entry. 0.13.0 does not store timezone information: 0.14.0 aligns to UTC: I'm not sure what's our the best approach, any suggestions? PS. sorry for multiple commits, this is my first PR |
…_to_delete_dataset_api Add Docstrings to Delete Dataset API
…ndtrip Add a test for roundtripping ExtensionArrays
…tothek into tz_bug_fix merge conflics
Co-Authored-By: Marco Neumann <57095103+marco-neumann-jdas@users.noreply.github.com>
fjetter
left a comment
There was a problem hiding this comment.
I think the github diff is a bit confused due to the many merge commits. We probably should squash this on merge.
| keys = np.array(list(self.index_dct.keys())) | ||
| labeled_array = pa.array(keys, type=self.dtype) | ||
| return np.array(labeled_array.to_pandas(date_as_object=date_as_object)) |
There was a problem hiding this comment.
This should already be on master. Is github fooling me or what's happening here?
There was a problem hiding this comment.
I have pulled the latest master before committing, I think GitHub is confused
There was a problem hiding this comment.
Seems like the rebase got a bit messed up. @ged-steponavicius could you perhaps try rebasing again on master?
Description:
fixes issue #259