You can't meaningfully subtract two dates and get a date. You can only get a delta in time.
Today when you subtract dates with SUBTRACT (and thus -), you get days...regardless of the resolution in seconds or nanoseconds:
>> x: now
== 22-Jan-2018/19:41:21-7:00
>> y: 12-Dec-2012/20:30:12-6:00
== 12-Dec-2012/20:30:12-6:00
>> x - y
== 1867
When people ask for a higher resolution answer they are pointed at DIFFERENCE:
>> difference x y
== 44808:11:09
I'm not sure why days were chosen as the default for subtract. But either way, this doesn't have a lot to do with what "difference" means in other contexts, as it's a mathematical/set differencing operation:
>> difference "abcd" "bdef"
== "acef"
That would be the so-called "symmetric difference", a.k.a. XOR. I'm going ahead with Ladislav's proposal that be what DIFFERENCE means on INTEGER!, along with INTERSECT being mathematical ANDing, and UNION being ORing. Hence:
and+: enfix tighten :intersect
or+: enfix tighten :union
xor+: enfix tighten :difference
This is all fine and good, with some small details I describe in Ladislav's ticket. (Are BINARY!s best thought of as bits you want to OR together, or as sets of bytes you want to union together?) But the big problem is how DIFFERENCE on DATE! has absolutely nothing at all to do with this.
What my leaning would be here would be that subtraction on DATE!s return the full resolution difference in time, so you're not losing information there. Then have some way to round times to a number of days. I don't know of any operation currently for getting the number of days out of a time, so here's an SO Question about that:
But perhaps returning days is too entrenched or there's a really good reason for it? :-/ In which case, some new operation is likely needed for measuring the time difference between dates.
Ideas?