Am Thu, 23 May 2019 11:18:43 +1200
schrieb Gavin Lambert via Boost-users
On 23/05/2019 00:30, Erik Thiele wrote:
if the time_duration datatype is a complete partial order which is for example needed for it to be able to be sorted, then the above output is partly illegal:
if not a
if a<=b and b<=a then must be a=b. but this is not the case.
not_a_date_time is like a NaN. NaNs are weird like that.
i don't think we should mix floating point issues with the date_time library.
Returning true for the <= and >= operations is probably actually a bug; it's a side effect of using less_than_comparable when it should be using partially_ordered instead. You should raise an issue about that on GitHub or submit a PR to fix it.
I will raise an issue.
so as expected the two vectors v0 and v1 are not equal after being sorted even though they certainly should be!
A default constructed time_duration is equal to zero duration. A not_a_date_time time_duration is not a zero duration. Why would you expect them to be equal?
I do not expect time_duration(not_a_date_time) and time_duration(hours(0)) to be equal. instead i expect them to be not equal. actually they are not equal, which is correctly reported by operator==. but i expect v0 and v1 to be equal because after sorting two vectors with the same contents must be equal. watch closely, v0 and v1 have the same elements. they are just push_backed in a different order. so after sorting v0 and v1, they need to be equal, but aren't. this is because operator< is not a complete partial order here.
i do not understand why time_duration is behaving in such a strange way here.
I am using time_duration(not_a_date_time) as a SQL-NULL value just like i am using date(not_a_date_time) and ptime(not_a_date_time) as SQL-NULL values.
SQL NULLs are weird, just like NaNs, so this should not be surprising to you.
I do not share the opinion that anything is weird :-) I was just looking for a reason for the asymmetry here. anyway i think it is not possible anymore to change this since there is too much code using the library out there and everybody is now used to this asymmetry. but the operator< issue can hopefully be fixed. i make a report. cu erik