Interested to talk a bit about this one.  There is currently no way to create a `Date` with `ol.expr.parse` (this is intentional).  And there is no way to determine that the string value in a node is a date when reading in a filter doc.  This test demonstrates that you've enabled writing ISO strings when someone uses a `Date` instance in a `ol.expr.Literal`, but I don't see where this will ever happen (except for this test).  The `ol.expr.Literal` constructor will only be used inside the library (it isn't exported), and the FE parsing code can never know when a string represents a date (we only make guesses about when a string represents a number).  And dates won't make their way into expressions from userland because `ol.expr.parse` doesn't provide a way to create a date.

The primitives that you can create in a string expression are intentionally `number`, `string`, `boolean`, and `null`.  I think it makes sense to keep it that way because it gives us flexibility in serializing - they are all well represented in JSON, and though they are poorly represented in XML, things get worse with `Date` and other objects.

If you want to write a filter with an ISO 8601 string for a date, I suggest creating a literal expression with the string value.