Currently, a quirk of how we coerce types allows for running Date and Numeric aggregations (e.g. DateHistogram and Histogram) over boolean field types. This will coerce the boolean into a number, which will be either zero or one, and then in the case of a date aggregation, treat that number as milliseconds since epoch for the date aggregation. This is almost definitely not a desirable behavior.
During the Values Source refactoring, we broke boolean fields out as a distinct Values Source Type, which now gives us the ability to explicitly target which aggs should and should not support boolean fields. In general, it makes sense to treat boolean fields closer to keyword fields for bucketing purposes, but continue to treat them as numerics for metric purposes (e.g. asking for the sum of a boolean field potentially carries useful information).
Currently, a quirk of how we coerce types allows for running Date and Numeric aggregations (e.g. DateHistogram and Histogram) over boolean field types. This will coerce the boolean into a number, which will be either zero or one, and then in the case of a date aggregation, treat that number as milliseconds since epoch for the date aggregation. This is almost definitely not a desirable behavior.
During the Values Source refactoring, we broke boolean fields out as a distinct Values Source Type, which now gives us the ability to explicitly target which aggs should and should not support boolean fields. In general, it makes sense to treat boolean fields closer to keyword fields for bucketing purposes, but continue to treat them as numerics for metric purposes (e.g. asking for the sum of a boolean field potentially carries useful information).