Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
UTCDateTime fuzzy comparisons break sorting, max, min #1766
changed the title from
test case and possible fix for #1765
UTCDateTime fuzzy comparisons break sorting, max, min
Apr 28, 2017
referenced this pull request
May 5, 2017
@barsch I just pushed a few changes, let me know what you think. All the UTCDateTime tests pass but there are lots of other (seemingly unrelated) failing tests that I will try to figure out later. We also need to rebase from current master before we can merge right?
I don't know - I have the feeling the safest bet would be to stay with integer/long data type while comparing objects to an
I think you are right. Best to leave it as a rounded int for comparison. I will pick this up again this weekend. Should I also attempt the rebase to current master? I am hoping that makes some of the other failures that seem unrelated go away.
I will also add a warning on setting attrs after init, thus paving the way to immutability in the future, if that is what we are going to do. Is there some kind of official process for making these sorts of decisions?
I'll be very happy if you take this PR over ;) - rebasing to master is needed - maybe even close this PR and open a new one if this is easier for you
immutability is afaik fine for most core developers, but maybe asking in Gitter gives some more input/thoughts on this matter