Gunnar Morling Your argument makes sense, and Date's javadoc seems to agree with you, though the local timezone is also assumed when parsing. And in some deprecated Date constructors.
The parsing was the main reason why I opened this ticket, actually: when developers provide indexNullsAs field attributes, the provided string is parsed, and in the case of a date, the local timezone is assumed when no other is provided. On the other hand, for Elasticsearch JSON queries, UTC is assumed. So when using a JVM with non-UTC local timezone, you end up having test failures because the assumptions are off... But I should probably fix the tests instead of changing Search's behavior.

So to sum up:

• For Date: Invalid. Maybe just rename or document org.hibernate.search.elasticsearch.util.impl.ElasticsearchDateHelper.ENCODING_TIME_ZONE to make it explicit that it's the timezone Dates are expected to be encoded in as per the Date javadoc.
• For Calendar: Invalid.

I'll do it ASAP.